Re: ld-linux.so.2 cannot process libpthread.so.0

[Mark Jessee <mjessee04 at gmail dot com>]

On 12/6/05, Nix <nix@esperi.org.uk> wrote:
> On Mon, 5 Dec 2005, Mark Jessee said:
> > Hi everyone, just thought I'd let you know that I managed to sort out
> > this problem, although I'm still not sure why.
> >
> > It turns out there are two files named libpthread.so.0 that are
> > required.  I originally ran 'ldd' on my program and it told me I
> > needed /lib/tls/libpthread.so.0.  I did some searching around and
> > found another file with the same name (but different contents)
> > /lib/libpthread.so.0, so I moved that one over to my target root file
> > system and now it works!
> >
> > However my program now seems to use the older LinuxThreads instead of
> > NPTL.  The 'ps' command now shows an entry for each thread, which I
> > think is the LinuxThreads behaviour.  I still need to make my program
> > work with NPTL, but for now have a workaround.
> >
> > Can anyone here confirm what the purpose of the files
> > /lib/libpthread.so.0 and /lib/tls/libpthread.so.0?  What do you
> > suggest I do to get NPTL working?  I really don't believe it is a
> > versioning issue since it works in a chroot environment on the same
> > flash card when I run it on my laptop.
>
> Back when NPTL was coming in, many buggy programs couldn't handle NPTL
> because they were dependent on non-POSIX features of LinuxThreads.
>
> So many distributions compiled glibc *twice*, once for LinuxThreads
> and once for NPTL, putting the LinuxThreads copy of glibc into /lib
> and the NPTL copy in /lib/tls, and configuring the NPTL copy with
> an --enable-kernel in the 2.6 range and the LinuxThreads copy with
> an --enable-kernel in the 2.4 range.
>
> If the resulting system ran on a system with the 2.4 kernel or without
> thread-local storage support, it automatically picked up the
> LinuxThreads copy of glibc in /lib: otherwise, it was assumed capable of
> handling NPTL and picked up the NPTL copy in /lib/tls. (This `hwcap'
> mechanism also allows things like inclusion of i686-specific libraries
> in /lib/i686, or even combinations like /lib/i686/tls. Alas it doesn't
> seem to be documented, which is a shame because it's very useful if you
> know it exists.)
>
> Note that you can't just copy /lib/libpthread*so around: it is tightly
> tied to the corresponding versions of libc, ld-linux, and so
> on. Combining an NPTL libc and a LinuxThreads libpthread is a recipe for
> locking problems and general nastiness. Combining an NPTL ld-linux and a
> LinuxThreads libpthread will probably be less horrible but is still
> risky. These days, almost everything works with NPTL; even difficult
> cases like user-mode-linux are acquiring support for it, so there's
> increasingly little reason to have a LinuxThreads-capable glibc on your
> system at all.
>
> --
> `Y'know, London's nice at this time of year. If you like your cities
>  freezing cold and full of surly gits.' --- David Damerell
>
>

How do I tell which threading library (LinuxThreads vs NPTL) my
program is running with on the target?  When I run it on my
development machine, 'top' shows 1 entry for the program.  On my
target, 'top' shows many entries for the program, 1 for each thread. 
Does this mean its using LinuxThreads?

I've now copied my entire /lib directory structure over to my target's
compact flash card.  I suspect (but haven't confirmed) that it still
refuses to use /lib/tls/libpthread.so.0 which is the NPTL library. 
Does anyone have any ideas why this might not be compatible?  My
target is AMD Elan (i586 compatible).

Mark