On Tuesday 26 October 2004 14:28, Jeremy Utley wrote:
> On Tue, 26 Oct 2004 13:31:04 +0200, BlaisorBlade
> <blaisorblade_spam@...> wrote:
> > > Which would mean that no binaries compiled on that system will be
> > > linked against NPTL, without modifying the LD_LIBRARY_PATH. IMHO,
> > > this still needs to be resolved in some way.
> > No, this is (slightly) false. Or better, I've read directly the document
> > on LD_ASSUME_KERNEL on Ulrich Drepper's homepage
> > (http://people.redhat.com/drepper/). The doc is at:
> > http://people.redhat.com/drepper/assumekernel.html
> > What happens on RedHat/FedoraCore:
> > - ld-linux.so.2 searches first /lib/tls, then /lib/i686, then /lib (which
> > is like modifying LD_LIBRARY_PATH, but hardcoded in the linker).
> Yep, and ld-linux.so.2 is the run-time linker.
> The binaries are still
> *compiled* against the Linuxthreads glibc,
Well, static binaries are compiled against /usr/lib/libc.a, which is non-NPTL.
So you are right for static binaries.
For dynamic binaries, they are linked against /usr/lib/libc.so, which
"includes" the references to libc.so.6. But no actual code is bundled, and
the references are resolved against whatever library is choosen by the
linker. So, for dynamic binaries (i.e. most ones, apart UML) your last
sentence is wrong.
If you wonder why /usr/lib/libc.so is used, the answer is
that /usr/lib/libc_nonshared.a contains some special wrappers, which call
functions like mknod() with a "mknod ABI version" argument.
> which I assume is what you
> meant by slightly incorrect.
"Slightly incorrect" meant that, actually, it is like setting
LD_LIBRARY_PATH="/lib/tls:/lib/i686:/lib"; only this is bundled within the
> This, of course, explains why only
> Gentoo (and the soon-to-be-released LinuxFromScratch 6.0) systems
> encounter this issue - as they do not create a LinuxThreads enabled
> glibc, and anything compiled on those two currently end up compiled
> against NPTL glibc.
UML is not the only app which breaks with NPTL. Why don't you try the double
> > > > > So UML will not run on NPTL-enabled gentoo-systems, since
> > > > > gentoo-ebuilds won't build two glibcs (actually they will in the
> > > > > future, but those ebuilds aren't stable yet).
> > > > > Will the right libc.so
> > > > > from /lib be loaded instead of the one from /lib/tls?
> > No, the /lib/tls one should get loaded, but in that case it seems to
> > work.
> Confirmed. On my home systems, I can take a UML binary compiled on an
> older build of LFS (one that still used LinuxThreads), transfer the
> binary onto a NPTL-lib-only system (no /lib/tls), and it works
> beautifully. Only when UML compiles against NPTL-compiled libc.so.6
> does it fail, and that failure is a constant.
> > Actually, I've never heard that UML has (unfixed) bugs when linked to
> > NPTL. Apart from link failures on recent glibc/toolchains :-(, which is
> > not your case.
> > > > On my MDK it works quite fine. And it has glibc2.3.3 (actually this
> > > > is meaningless, since distros anyway must use snapshots).
> > >
> > > MDK's glibc, even in 10.0, is NOT using NPTL - it's still using
> > > linuxthreads - to see, run the /lib/libc.so.6 from a shell prompt, and
> > > see the output - you'll note there's no mention of NPTL.
> > You still refuse to take a look at my point. Look at the /lib/tls one,
> > which is NPTL-enabled. Neither RH/FC nor Mandrake, nor I guess SuSE, put
> > a NPTL enabled glibc in /lib. /lib/tls is the right location.
> Which exactly proves my point. /lib/tls is not a part of the compile
> time library search path, so the UML compile does not link to a NPTL
> glibc. ld-linux.so.2 includes it at run time, which does not expose
> the problem. And if this dual-libc setup is the "right thing" to do,
> it begs to wonder why the glibc sources, as downloaded from CVS, don't
> do this by default - I know, not your area.
I think that's likely. Probably you'll have to look either at Gentoo new
ebuilds or at FC source RPMs.
> > The only current distro without NPTL support, for what I know, is
> > Slackware 10.0.
> > > What needs to happen is for someone VERY familiar with the UML code to
> > > dig in, and find out why the binutils assertion failure keeps tripping
> > > up. That's the only error that currently comes about, and it causes
> > > any UML kernel to segfault immediately upon execution. I have straces
> > > available of the linux binary showing where it segfaults.
> > I can get the assertion failure on FC2 - 64bit. I think I could run the
> > binary, but I would not be surprised that I forgot to actually make sure
> > of that.
> I get the assertion failure on ANY UML compile linked against NPTL
> glibc at compile-time, as opposed to just at run-time, irregardless of
> what versions of gcc and binutils I use (I've tried this on as low as
> 2.14 FSF binutils and GCC 3.3.3).
Here is what I use for binutils:
root [~: 15:35 (0)] # ld -v
GNU ld version 220.127.116.11.7 20031029
> In case it helps you, this web link
> has strace output from a UML kernel binary compiled against a
> NPTL-only glibc:
So the assertion failure comes or does not with the SAME binutils but
> > The first thing I'm trying to do is to add "executable_start" as in the
> > default ld linker scripts. When it will work, I'll let you know.
> Great! Please let me know if there's anything I can do to help - I'm
> not much of a coder, but I've always got spare CPU cycles to test
> things out, and the offer I made before of a shell on a NPTL-only
> system still stands.
My current Gentoo installation is of that kind. I still need to switch to
Gentoo, and the failure with 2.6.9 host kernels is pretty urgent. Plus I need
to release an updated patch for the 2.4 kernel tree.
However, I'm working on this, too.
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729