[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Glibc-2.6 (was Re: Error from coreutils CVS version)
From: |
James Youngman |
Subject: |
Re: Glibc-2.6 (was Re: Error from coreutils CVS version) |
Date: |
Fri, 18 May 2007 09:18:46 +0100 |
On 5/18/07, Greg Schafer <address@hidden> wrote:
Alexander Kahl wrote:
> gcc -std=gnu99 -I. -march=pentium4 -O2 -pipe -fomit-frame-pointer -s
-fgnu89-inline -c utimecmp.c
> In file included from utimecmp.c:33:
> utimens.h:2: error: conflicting types for 'futimens'
> /tools/include/sys/stat.h:370: error: previous declaration of 'futimens' was
here
> make[2]: *** [utimecmp.o] Error 1
> make[2]: Leaving directory `/mnt/lfs/coreutils-build/coreutils/lib'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/mnt/lfs/coreutils-build/coreutils/lib'
> make: *** [all-recursive] Error 1
>
> using newest glibc from cvs
Hmmmm, Glibc-2.6 is now released and coreutils-6.9 doesn't compile
against it because of this error. It seems Glibc has now gained
futimens() and it disagrees with the Coreutils implementation.
In fact this is probably a gnulib issue. The prototypes for the
relevant functions in the current Austin Group draft document are:-
int futimens(int fd, const struct timespec times[2]);
int utimensat(int fd, const char *path, const struct timespec
times[2], int flag);
/* flag may contain AT_SYMLINK_NOFOLLOW */
The current gnulib implementation of futimens() is more like
utimensat() than the futimens() above, or so a cursory examination
leads me to believe.
The underlying problem here I suppose is that both gnulib and glibc
are tracking an as-yet-not-final standard document.
James.