Paul Eggert <[EMAIL PROTECTED]> wrote:
> I'll submit an alternate patch to coreutils so that it works around
> this glibc glitch. The simplest workaround is to not invoke utimes
> when building with glibc; perhaps I can improve on that, but I don't
> know.
We don't have to condemn the coreutils always
to use the inferior utime interface on glibc systems.
Instead, I'm adding a configure-time test of utimes, so that
if it works, coreutils will use it.
Here's the C program it'll compile and run.
So far it compiles and exits successfully on all systems listed
except for the one with Debian libc6 version 2.3.2-1.
/* tested with gcc on the following:
AIX 4.3 (both gcc and cc)
openbsd 3.2
solaris 9
netbsd 1.6
OSF1 V4.0 (both gcc and cc)
linux 2.4.20, 2.4.21
*/
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <utime.h>
int
main ()
{
static struct timeval timeval[2] = {{9, 10}, {11, 12}};
struct stat sbuf;
char const *file = "x";
FILE *f;
exit ( ! ((f = fopen (file, "w"))
&& fclose (f) == 0
&& utimes (file, timeval) == 0
&& lstat (file, &sbuf) == 0
&& sbuf.st_atime == timeval[0].tv_sec
&& sbuf.st_mtime == timeval[1].tv_sec) );
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
