This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc-2.3.4 test suite failure


Nix wrote:
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 :)


Many thanks for your help. Unfortunately it still fails. The first thing is the catgets test then with nptl Expected signal 'Alarm clock' from child, got none and then tst-cond16/17/18/19/20 (then I stopped it)

Probably I'll have to tried to build it from scratch,
i.e. generating a new 'Linux-From-Scratch' on an emtpy
partition.

Thanks,
Helmut.

---
Helmut Jarausch
RWTH-Aachen University
Germany


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]