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


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


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