This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: apply gnulib test suite to glibc
Paul Pluzhnikov wrote:
> > $ ./gnulib-tool --create-testdir --dir=/tmp/testdir \
> > --with-tests --single-configure \
> > `./posix-modules`
>
> This failed with missing gperf. Perhaps gnulib-tool should check for
> its dependencies?
The dependencies are documented in gnulib's DEPENDENCIES file.
The need for gperf comes from particular modules ('iconv_open');
gnulib-tool as a generic tool does not know about it.
> This step appears to be using installed glibc with messages like:
> ...
> checking for library containing gethostbyname... (cached) none required
> checking for gethostbyname... (cached) yes
> checking whether hypot works according to ISO C 99 with IEC 60559... yes
> checking for hypotf... yes
> ...
This first 'configure' run, triggered by gnulib-tool, is soon followed
by "make distclean". It does not matter which libc and which compiler is
used in this step.
> > 3. In /tmp/testdir, run
> > $ ./configure CPPFLAGS="-Wall"
>
> This also uses installed glibc.
Yes, it would be useful if <http://sourceware.org/glibc/wiki/Testing/Builds>
would contain instructions how to set the CC variable (and possibly other
environment variables) when configuring GNU packages that should use
a glibc from source. Or if environment variables don't suffice, how to
set up a chroot environment or a Hydra/NixOS [1] environment with such
a glibc build?
> > $ make
> > Verify that Gnulib has built no replacement/workaround code
> > (gllib/*.o files) - if so, this indicates problems in the libc.
>
> Using installed Ubuntu EGLIBC 2.11.1-0ubuntu7.10, I get 85 *.o files
> there. Here is a sample:
>
> gllib/allocator.o
> gllib/areadlinkat.o
> gllib/areadlink.o
> gllib/asnprintf.o
> gllib/basename-lgpl.o
> gllib/careadlinkat.o
> gllib/c-ctype.o
> gllib/chdir-long.o
> gllib/cloexec.o
> gllib/c-strcasecmp.o
Most of these files come from auxiliary compilation units that don't
correspond to a POSIX/GNU function and therefore don't point to a bug.
(The usual gnulib-tool option for avoiding these unnecessary compilation
units does not yet work in combination with --with-tests.)
The ones that do are (on glibc 2.14.1):
ioctl.o
This is due to
checking for ioctl with POSIX signature... no
Wrong parameter type: 'unsigned long' rather than 'int'.
<http://www.gnu.org/software/gnulib/manual/html_node/ioctl.html>
strerror_r.o
This is due to
checking for strerror_r with POSIX signature... no
When _GNU_SOURCE is defined, glibc defines strerror_r with a non-POSIX
declaration.
<http://www.gnu.org/software/gnulib/manual/html_node/strerror_005fr.html>
fclose.o
fflush.o
fseek.o
fseeko.o
This is due to
checking whether fflush works on input streams... no
<http://www.gnu.org/software/gnulib/manual/html_node/fclose.html>
<http://www.gnu.org/software/gnulib/manual/html_node/fflush.html>
<http://sourceware.org/bugzilla/show_bug.cgi?id=12799>
<http://sourceware.org/bugzilla/show_bug.cgi?id=12724>
nanosleep.o
This is due to
checking for working nanosleep... no (mishandles large arguments)
This function mishandles large arguments when interrupted by a signal on
64-bit Linux platforms.
<http://www.gnu.org/software/gnulib/manual/html_node/nanosleep.html>
fcntl.o
This is due to
checking whether fcntl understands F_DUPFD_CLOEXEC... needs runtime check
The Linux kernel only added F_DUPFD_CLOEXEC in 2.6.24, so we always replace
it to support the semantics on older kernels that failed with EINVAL.
futimens.o
This is due to
checking whether futimens works... needs runtime check
The Linux kernel added futimens in 2.6.22, but has bugs with UTIME_OMIT
in several file systems as recently as 2.6.32. Always replace futimens
to support older kernels.
<http://www.gnu.org/software/gnulib/manual/html_node/futimens.html>
linkat.o
This is due to
checking whether linkat(,AT_SYMLINK_FOLLOW) works... need runtime check
Linux added linkat in 2.6.16, but did not add AT_SYMLINK_FOLLOW
until 2.6.18. Always replace linkat to support older kernels.
utimensat.o
This is due to
checking whether utimensat works... needs runtime check
The Linux kernel added utimensat in 2.6.22, but has bugs with UTIME_OMIT
in several file systems as recently as 2.6.32. Always replace utimensat
to support older kernels.
<http://www.gnu.org/software/gnulib/manual/html_node/utimensat.html>
glob.o
This is due to
checking whether glob lists broken symlinks... no
Gnulib expects glob() to return symlinks whose target doesn't exist.
<http://www.gnu.org/software/gnulib/manual/html_node/glob.html>
dprintf.o
fprintf.o
printf.o
snprintf.o
sprintf.o
vasnprintf.o
vdprintf.o
vfprintf.o
vprintf.o
vsnprintf.o
vsprintf.o
This is due to
checking whether printf supports infinite 'long double' arguments... no
glibc's fprintf produces random output when 'long double' values outside
the IEEE range are given. Gnulib developers don't find this is OK and
prefer "nan" output.
Related: <http://sourceware.org/bugzilla/show_bug.cgi?id=4586>
<http://sourceware.org/ml/libc-hacker/2007-06/msg00006.html>
isfinite.o
This is due to
checking whether isfinite(long double) works... no
isfinite() returns true for 'long double' arguments that are outside
the IEEE range.
<http://www.gnu.org/software/gnulib/manual/html_node/isfinite.html>
pwrite.o
This is due to a gnulib bug. Fixed now.
remove.o
This is due to a gnulib autoconf test that is too pessimistic.
> While it's conceivable that there are 85 bugs discovered so far, how
> do I figure out what's wrong with e.g. glibc's strerror ?
For each of the .o files that should not be there, I checked the gnulib
documentation, the comments in the autoconf tests (.m4 file), the configure
output, and the config.log file.
Bruno
[1] http://hydra.nixos.org/project/gnu