This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: glibc-2.3.4 test suite failure
- From: Nix <nix at esperi dot org dot uk>
- To: Helmut Jarausch <jarausch at skynet dot be>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Mon, 07 Feb 2005 12:57:19 +0000
- Subject: Re: glibc-2.3.4 test suite failure
- References: <cu62vf$ahd$1@sea.gmane.org>
On Sun, 06 Feb 2005, Helmut Jarausch stated:
> Hi
> I'd very much appreciate your help.
>
> I have build glibc-2.3.4 from 2005/01/27 under
> linux kernel 2.6.10 (i386) and binutils-2.15.94.0.2 .
> Unfortunately, some tests fail, especially the
> catgets test and several of the nptl tests.
It isn't clear from the info you've provided --- knowing exactly which
tests failed is important --- but one of these things is arguably
wrong...
> I've configured it as
> ../glibc-2.3.4/configure --prefix=/usr --enable-add-ons=nptl \
> --with-tls --with-__thread --disable-profile \
> --enable-kernel=2.6.10 --with-headers=/usr/src/linux/include \
... which is that pointing at /usr/src/linux/include is iffy. You should
use Mariusz Mazur's linux-libc-headers-2.6.10.0 package instead; copy
the include/asm-i386 and include/linux subdirectories to
/usr/include/asm and /usr/include/linux, and configure glibc *without*
the --with-headers option.
The Linux headers themselves are not meant for userspace programs at
all, anymore.
FWIW, I had no problems building glibc/NPTL on i686 from the glibc-2_3_4
release with exactly the configuration you describe.
(Note that you *will* get spurious NPTL test failures if your ulimits
specify a too-small stack; it's best to set that limit to unlimited for
the purpose of glibc testing.)
One sanity test I've found useful in the past is to copy my root
filesystem somewhere under /tmp[1], install glibc there with `make
install install_root=', then rbind-mount all the other filesystems into
the appropriate places underneath your temporary directory and chroot
into there. The resulting chroot has everything glibc needs with the
exception of up-to-date iconv and i18n stuff (which is installed into
/usr, so covered by your bind mount), and is generally good enough for
testing out a few of your most demanding threaded programs as a final
sanity check. (This is particularly useful if you're trying to build a
unified LinuxThreads/NPTL installation and want to make sure you've
not mixed something up.)
Obviously, if `make check' fails, something is probably wrong and
you should find out what it is and/or fix it :)
[1] or somewhere temporary where devices and suid binaries are
permitted
--
`anybody who quotes Russ [Allbery] can be forgiven almost anything!'
-- Stephen J. Turnbull