This is the mail archive of the libc-alpha@sourceware.org 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: ld-linux.so.2 cannot process libpthread.so.0


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


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