tls tests fail of gcc-4.0.3 and glibc errors in nptl; what to do now?

Ken Moffat ken at linuxfromscratch.org
Sun Jan 7 14:05:32 PST 2007


On Sun, Jan 07, 2007 at 09:05:51PM +0100, lynx.abraxas at freenet.de wrote:
> 
> I'm  sorry  my  mail is not clear. I have an LFS 5.1.1 nearly  three years old
> and pretty big, so I'm not happy with doing a new LFS if I can't  use  what  I
> did in BLFS sinc then.

 Upgrading is the one thing we probably don't cover well in the LFS
book.  For a server, you can go years with only security fixes, but
for a desktop (at least, for gnome and kde), a lot of things only a
year old are antiquated.  If you have a spare partition on a
desktop, you can use what you have to build the new system, and then
perhaps dual-boot between the new and old until the new desktop is
finished.  If you can't do that, upgrading is less convenient (or
even totally painful).  But, all source-built distros eventually
exceed their time to live.
> 
> >
> >  I'm not familiar with x264 (nor multiprocessors, nor wine), but if
> > you are intending to upgrade glibc on a running system, you have a
> > good chance of breaking things.  If you build from source, you
> > should expect to build a new system from time to time.
> 
> Well  I  already  got  some info on upgrading glibc micro versions (upgrade of
> libc-2.3.3.so to libc-2.3.6.so problematic? at the list).
> It should work if the new glibc has no errors.
>

 Sure.  Personally, I wouldn't attempt it - I've seen too many
problems caused by people branching out on their own and upgrading
the toolchain (me included, but at least I've got enough systems to
always have something that works).
> 
> >
> >  I can't find sched_affinity in any headers on my current system, so
> > I guess it is a kernel syscall - in that case, and given that it
> > apparently doesn't work for you with 2.6.19.1, maybe it's the
> > include/linux headers which cause the compiler to call it with the
> > wrong args.  If so, upgrading glibc is unlikely to help, and changing
> > include/linux under a running system is likely to break things.
> 
> I can't say where I found the info about sched_affinity but it said that  only
> glibc-2.3.3  had  it  with  3 params and newer versions with only 2 again. But
> this isn't a big problem at all. More the thing with wine.
> 
 Well, you might do better asking on blfs-support about wine,
although I doubt there are many people who use it.
 
> >
> >  You also say you are "trying to compile a gcc-4.0.3", but then you
> > appear to already have a version of gcc-4.0.3, which you have use to
> > build gcc:
> 
> The error grep is from glibc-2.3.6  compilation  onec  done  with  my  default
> gcc-4.1.1 and once with the gcc-4.0.3 in /opt with its tls failures.
> 
[...]
> 
> Well more detailed parts of glibc-check-log0:
> 
> GCONV_PATH=/usr/src/glibc/glibc-build/iconvdata                       LC_ALL=C
> /usr/src/glibc/glibc-build/elf/ld-linux.so.2                    --library-path
> /usr/src/glibc/glibc-build:/usr/src/glibc/glibc-
> build/math:/usr/src/glibc/glibc-build/elf:/usr/src/glibc/glibc-
> build/dlfcn:/usr/src/glibc/glibc-build/nss:/usr/src/glibc/glibc-
> build/nis:/usr/src/glibc/glibc-build/rt:/usr/src/glibc/glibc-
> build/resolv:/usr/src/glibc/glibc-build/crypt:/usr/src/glibc/glibc-build/nptl
> /usr/src/glibc/glibc-build/nptl/tst-cancel17      >      /usr/src/glibc/glibc-
> build/nptl/tst-cancel17.out
> Didn't expect signal from child: got `Segmentation fault'
> make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancel17.out] Error 1
[...]
> make[2]: *** [/usr/src/glibc/glibc-build/nptl/tst-cancelx4.out] Error 1
> 
> Where   as   in  /usr/src/glibc/glibc-build/nptl/tst-cancelx4.out  and  others
> similar:
> 
> package    glibc:/usr/src/glibc/glibc-build>     cat     /usr/src/glibc/glibc-
> build/nptl/tst-cancelx4.out
> cleanup handler not called for 'read'
> cleanup handler not called for 'readv'
> cleanup handler not called for 'select'
[...]
> cleanup handler not called for 'msgrcv'
> early cancel test of 'read' successful
[...]
 Ah, to me those results (not the segmentation fault, which might be
something to worry about) look eerily similar to the sort of results
I've seen from glibc-2.5 (development book).  Scary, but I've not
seen any problems I can blame on it.  Full disclosure: I'm using
athlon64s for LFS - since I moved one of them back to x86 from clfs
(using the LFS-6.1 I'd initially used to build my first pure64
system) I've had a number of spontaneous reboots in LFS, now with
kernel 2.6.19.1 I get what appear to be oops's (in X) although
nothing ever gets to the logs - doesn't seem any _worse_ with
glibc-2.5 and its nptl test failures, but who knows for sure?  Ditto
the second machine, which was ok with clfs-1.0.0 (x86) [ glibc-2.4 ]
and 2.6.17.x but again flashes the keyboard LEDs at me from time to
time on the glibc-2.5 system.

 The 'successful' messages are OK, it's the 'not called' which are
the failures.  After looking at results from glibc-2.5, I suspect the
c++ compiler, or the kernel, doesn't do what the test expects.  But,
as with most toolchain issues, I should be regarded as 'ignorant'.

> 
> And in /usr/src/glibc/glibc-build/nptl/tst-cleanupx4.out:
> 
> package     glibc:/usr/src/glibc/glibc-build>     cat    /usr/src/glibc/glibc-
> build/nptl/tst-cleanupx4.out
> test 0
> clh (2)
> global = 2, expected 15
> test 1
> clh (4)
> clh (5)
> clh (6)
> global = 156, expected 276
> test 2
> clh (7)
> clh (8)
> global = 64, expected 120
> test 3
> clh (2)
> clh (9)
> clh (10)
> global = 280, expected 460
>
 Unusual!
> 
> Others have no errors at all in glibc. The segfault isn't nice  I'd  say.  The
> tst-cleanupx4  error  didn't happen again when I removed tst-cleanupx4.out and
> did make -k check again.
 So that might be an erratic problem, perhaps caused by kernel
changes (remember that building glibc-2.3.5 from 2.3.3 using gcc-4+
and kernel 2.6.19.1 is a most uncommon choice, building against
the kernel headers from 2.4.26 is even less common.
> 
> I hope this makes it more clear.
> Lynx

 Yes, it's clear, but my advice is still the same.  To the extent
that you are deviating from the LFS book (in-place glibc upgrade,
multiple toolchains) you are "ploughing your own furrow" as we say
in English - If you hit the same problems as other people, you can
get help.  If you hit your own unique problems, you are on your own.

 If you had multiple machines/systems, I'd be interested in hearing
your experiences after upgrading glibc.  But, if this is your sole
system, your priority should probably be to keep something usable.
At the very least, make sure you can recover from backups if you do
decide to upgrade (that might involve a 'rescue' or 'Live' CD, but
you need to be able to access the backups from it, which can be an
interesting exercise if you only have one CD drive). 

ĸen 
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the lfs-support mailing list