glibc-2.3.4 test suite failure

[Helmut Jarausch]

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