Problems building current CVS version under Cygwin
I downloaded the CVS version of wget today and tried to build it under
the latest (1.15-14) Cygwin. I hit two compilation problems, both in
src/ptimer.c.
1. The first problem is with the test for _POSIX_MONOTONIC_CLOCK on line
186. That line is:
#if _POSIX_MONOTONIC_CLOCK >= 0/* -1 means not supported */
Under Cygwin, _POSIX_MONOTONIC_CLOCK is not defined, so cpp uses a
default value of 0 in the test. This causes the test to succeed, and
ptimer.c tries to compile "sysconf(_SC_MONOTONIC_CLOCK)" which fails.
A fix (but possibly not the most portable fix) for this is to change the
test:
#if defined(_POSIX_MONOTONIC_CLOCK) && (_POSIX_MONOTONIC_CLOCK >= 0)
2. The second problem is a little more annoying. Under Cygwin,
clock_getres() is properly defined in time.h, but there is no librt.a to
resolve the reference. A possible workaround is to a) add a test for
clock_getres to aclocal.m4, and b) wrap the code in ptimer.c that calls
clock_getres() in a #if HAVE_CLOCK_GETRES conditional.
I have attached a patch implementing these two fixes, if anyone is
interested.
With these two problems resolved, the CVS version of wget is running
great under Cygwin. In a day or two, I should know if the >2G file
support is working as well...
Thanks!
KM
diff -ur wget.orig/aclocal.m4 wget/aclocal.m4
--- wget.orig/aclocal.m42005-04-08 01:41:08.0 +0200
+++ wget/aclocal.m4 2005-04-08 16:14:40.078125000 +0200
@@ -85,6 +85,9 @@
AC_CHECK_FUNCS(clock_gettime, [], [
AC_CHECK_LIB(rt, clock_gettime)
])
+ AC_CHECK_FUNCS(clock_getres, [], [
+AC_CHECK_LIB(rt, clock_getres)
+ ])
])
dnl Check whether we need to link with -lnsl and -lsocket, as is the
diff -ur wget.orig/src/ptimer.c wget/src/ptimer.c
--- wget.orig/src/ptimer.c 2005-04-08 14:09:02.046875000 +0200
+++ wget/src/ptimer.c 2005-04-08 15:10:27.25000 +0200
@@ -183,13 +183,14 @@
{
struct timespec res;
-#if _POSIX_MONOTONIC_CLOCK >= 0 /* -1 means not supported */
+#if defined(_POSIX_MONOTONIC_CLOCK) && (_POSIX_MONOTONIC_CLOCK >= 0) /* -1
means not supported */
if (sysconf (_SC_MONOTONIC_CLOCK) > 0)
posix_clock_id = CLOCK_MONOTONIC;
else
#endif
posix_clock_id = CLOCK_REALTIME;
+#if HAVE_CLOCK_GETRES
if (clock_getres (posix_clock_id, &res) < 0)
{
logprintf (LOG_NOTQUIET, _("Cannot read clock resolution: %s\n"),
@@ -198,6 +199,10 @@
res.tv_sec = 0;
res.tv_nsec = 100;
}
+#else
+ res.tv_sec = 0;
+ res.tv_nsec = 100;
+#endif
posix_resolution = res.tv_sec * 1000.0 + res.tv_nsec / 100.0;
/* Guard against clock_getres reporting 0 resolution; after all, it
Re: Problems building current CVS version under Cygwin
Keith Moore <[EMAIL PROTECTED]> writes: > I downloaded the CVS version of wget today and tried to build it > under the latest (1.15-14) Cygwin. Thanks for the report. Please note that ptimer.c has undergone additional changes today, so you might want to update your source. > 1. The first problem is with the test for _POSIX_MONOTONIC_CLOCK on line > 186. That line is: > > #if _POSIX_MONOTONIC_CLOCK >= 0/* -1 means not supported */ > > Under Cygwin, _POSIX_MONOTONIC_CLOCK is not defined, so cpp uses a > default value of 0 in the test. That has since been fixed, much the way you describe. > 2. The second problem is a little more annoying. Under Cygwin, > clock_getres() is properly defined in time.h, but there is no librt.a to > resolve the reference. I don't get it -- if clock_getres is unavailable, then why does Cygwin declare support for POSIX timers? Maybe we should simply use gettimeofday, or even Windows timers, under Cygwin?
Re: Problems building current CVS version under Cygwin
Hrvoje Niksic wrote: > Thanks for the report. Please note that ptimer.c has undergone > additional changes today, so you might want to update your source. Will do. > I don't get it -- if clock_getres is unavailable, then why does Cygwin > declare support for POSIX timers? Maybe we should simply use > gettimeofday, or even Windows timers, under Cygwin? I cannot answer that question. I will post it to the Cygwin list and provide any answers here. FWIW - POSIX timers appear to be partially supported. clock_gettime() is present, but there is no librt.a, so it's in a nonstandard place (unless I am totally missing something). KM
Re: Problems building current CVS version under Cygwin
Keith Moore <[EMAIL PROTECTED]> writes: > FWIW - POSIX timers appear to be partially > supported. clock_gettime() is present, but there is no librt.a, so > it's in a nonstandard place (unless I am totally missing something). Wget doesn't require clock_gettime to be exactly in librt.(so|a), but it has to be *somewhere*. But if I understand your first report, the problem is not the lack of clock_gettime, but of clock_getres, and that's what Wget is not prepared to handle. It (naively) assumes that, if the implementation defines _POSIX_TIMERS, that they are actually implemented. Serves me right for trying to use an API designed after 1985.
Re: Problems building current CVS version under Cygwin
Hrvoje Niksic wrote: > Keith Moore <[EMAIL PROTECTED]> writes: > > >>FWIW - POSIX timers appear to be partially >>supported. clock_gettime() is present, but there is no librt.a, so >>it's in a nonstandard place (unless I am totally missing something). > > > Wget doesn't require clock_gettime to be exactly in librt.(so|a), but > it has to be *somewhere*. But if I understand your first report, the > problem is not the lack of clock_gettime, but of clock_getres, and > that's what Wget is not prepared to handle. It (naively) assumes > that, if the implementation defines _POSIX_TIMERS, that they are > actually implemented. Serves me right for trying to use an API > designed after 1985. Yes, it's the missing clock_getres() that's the problem. I asked about this on the Cygwin list, and I received a quick (if brief) reply: Christopher Faylor wrote: > On Fri, Apr 08, 2005 at 10:32:19PM +0200, Keith Moore wrote: > >>/usr/include/sys/features.h defines _POSIX_TIMERS, presumably to >>indicate that POSIX timers are supported. There seems to be something >>missing, though. >> >>Under the influence of _POSIX_TIMERS, /usr/include/time.h defines >>function prototypes for clock_gettime() and clock_getres() (and a few >>others). clock_gettime() gets linked-in from libc.a, but I cannot find >>a library for clock_getres(). >> >>This is causing problems for the CVS version of wget, which assumes >>_POSIX_TIMERS means all of the POSIX timer APIs are supported. >> >>Am I missing something here? Is there a clock_getres() somewhere? > > > No, there isn't. Sorry. So, there's the answer. Cygwin's POSIX timer support is incomplete. I'm not a Cygwin expert, but I suspect getting this API added would not be too terribly painful. However, even if that were to happen, it would mean wget would require a recent (and currently undeveloped/untested/unreleased) version of Cygwin to run in the Cygwin environment. Bummer. If there's anything I can do to help, please let me know. For example, I can do regular "sanity test" builds under Cygwin. Thanks for wget! KM
Re: Problems building current CVS version under Cygwin
Keith Moore <[EMAIL PROTECTED]> writes: >> No, there isn't. Sorry. [...] > So, there's the answer. Cygwin's POSIX timer support is incomplete. Then why on earth do they #define _POSIX_TIMERS? It's easy enough to add a configure test for clock_getres, but it's damn annoying to have to do so in the brave new world of POSIX. I'd rather simply have sysdep.h #undef _POSIX_TIMERS under Cygwin.
Re: Problems building current CVS version under Cygwin
I've now fixed this by simply having Cygwin use the Windows high-res timers, which are very precise. When Cygwin is fixed, we can revert it to use POSIX timers, like god intended.
Re: Problems building current CVS version under Cygwin
Hrvoje Niksic wrote: > I've now fixed this by simply having Cygwin use the Windows high-res > timers, which are very precise. > > When Cygwin is fixed, we can revert it to use POSIX timers, like god > intended. > > I grabbed the current CVS sources. They build & work fine under Cygwin. Thanks, KM
