Paul Eggert <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: >> gethrxtime uses clock_gettime on Linux systems (and any other system >> without nanouptime), so such systems will get link errors for >> clock_gettime if it's in a separate library like -lrt. > > Sorry, I didn't test with new-enough GNU/Linux systems. I installed > this further patch to work around the problem. This is "make check" > tested with Debian GNU/Linux 3.0 and 3.1-beta (x86), Solaris 8 64-bit > sparc (Forte 6 cc), Solaris 9 32-bit sparc (Forte 7 c89), and OpenBSD > 3.4 x86. > > 2005-02-21 Paul Eggert <[EMAIL PROTECTED]> > > * m4/xnanosleep.m4: New file. > * lib/Makefile.am (libfetish_a_SOURCES): Remove xnanosleep.c, > xnanosleep.h; now done by ../m4/xnanosleep.m4 automatically. > * m4/gethrxtime.m4 (gl_PREREQ_GETHRXTIME): Require gl_CLOCK_TIME, > gl_USE_SYSTEM_EXTENSIONS. Check whether CLOCK_MONOTONIC is > defined, and set LIB_GETHRXTIME accordingly. This is needed > for newer GNU/Linux systems that have clock_gettime, so that they > link in the appropriate library for it when needed. > * m4/prereq.m4 (gl_PREREQ): Require gl_XNANOSLEEP. > * src/Makefile.am (dd_LDADD, shred_LDADD): Add $(LIB_GETHRXTIME). > (nanosec_libs): Add $(LIB_XNANOSLEEP). Needed for newer GNU/Linux > hosts with clock_gettime.
Hi Paul, Thanks for doing that. This all started with the lament, http://bugs.debian.org/122639, that sleep(1) require linking with librt and hence libpthread on a system with a Linux kernel. Currently, coreutils' lib/xnanosleep.c needs -lrt solely to work around a bug in the Linux kernel's implementation of nanosleep. /* POSIX.1-2001 requires that when a process is suspended, then resumed, nanosleep (A, B) returns -1, sets errno to EINTR, and sets *B to the time remaining at the point of resumption. However, some versions of the Linux kernel incorrectly return the time remaining at the point of suspension. Work around this bug on GNU/Linux hosts by computing the remaining time here after nanosleep returns, rather than by relying on nanosleep's computation. */ #ifdef __linux__ enum { NANOSLEEP_BUG_WORKAROUND = true }; #else enum { NANOSLEEP_BUG_WORKAROUND = false }; #endif But it looks like that bug was fixed sometime between linux-2.6.8 (which has the bug) and linux-2.6.10, which apparently does not. So if configure automatically detects whether xnanosleep needs the workaround, binaries built for the newer systems won't have to use the work-around code or -lrt. I've written a test program to do that and will post it separately, to [EMAIL PROTECTED] That exercise led me to discover that a variant of this Linux kernel bug makes sleep malfunction, at least on linux-2.6.8.1 systems. Sleep fails when suspended and then resumed on such systems: $ sleep 9 & pid=$! [1] 6451 $ kill -TSTP $pid; kill -CONT $pid sleep: cannot read realtime clock [1]+ Exit 1 sleep 9 We can fix it with this patch: 2005-02-27 Jim Meyering <[EMAIL PROTECTED]> * xnanosleep.c (xnanosleep): Work around bug in Linux-2.6.8.1's nanosleep whereby it fails without setting errno upon being resumed after being suspended. Index: lib/xnanosleep.c =================================================================== RCS file: /fetish/cu/lib/xnanosleep.c,v retrieving revision 1.11 diff -u -p -r1.11 xnanosleep.c --- lib/xnanosleep.c 21 Feb 2005 08:10:47 -0000 1.11 +++ lib/xnanosleep.c 25 Feb 2005 23:46:23 -0000 @@ -123,9 +123,10 @@ xnanosleep (double seconds) ts_sleep.tv_nsec = BILLION - 1; } + errno = 0; if (nanosleep (&ts_sleep, NULL) == 0) break; - if (errno != EINTR) + if (errno != EINTR && errno != 0) return -1; if (NANOSLEEP_BUG_WORKAROUND) I'll probably check that in. The alternative is to provide a nanosleep wrapper that sets errno in this case. But the only uses of nanosleep in coreutils are through xnanosleep, so it's probably not worth it, there. If any of you know of a package that uses nanosleep where this would matter, please provide details. Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
