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

[Nix <nix at esperi dot org dot uk>]

On Tue, 6 Dec 2005, Mark Jessee worried:
> 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?

If `ps -LC programname' shows multiple entries for the target with
the same PID, e.g.:

  PID   LWP TTY          TIME CMD
 6801  6801 pts/35   00:16:49 galeon
 6801  6810 pts/35   00:00:03 galeon
 6801  6828 pts/35   00:00:00 galeon

or if /proc/{pid}/task has more than one directory in it (which works
even if your ps is too old to support -L):

nix@hades 85 /home/nix% ls /proc/6801/task
6801  6810  6828

then that task is using NPTL.

> 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. 

You can prove this by setting the LD_DEBUG environment variable to
`libs' immediately before running the program, typically via something
like

LD_DEBUG=libs misbehaving-program

and take a look at which libraries it's linking with. LD_DEBUG=help
lists some extra debugging options, some of which might prove helpful.

> Does anyone have any ideas why this might not be compatible?  My
> target is AMD Elan (i586 compatible).

It's more likely to be the kernel you're running, or perhaps the
compiler you compiled your target glibc with, than your CPU. (GCC
must support thread-local storage on the target for NPTL to work.)

In general I've found NPTL to be a little more fiddly to get working on
new targets than LinuxThreads: it imposes higher requirements on the
kernel and to some degree on the compiler. However, the result is so
much better than LinuxThreads that this effort is invariably worth
it. (I haven't heard anyone say `thank you for an amazing piece of work'
to Ulrich yet, so, er, in case he's reading, thank you; NPTL is so much
better than competing kernel-threads implementations that it's simply
not true, and it was done without turning either the kernel or glibc
into a horrid mess as well. Amazing stuff. :) )

-- 
`Y'know, London's nice at this time of year. If you like your cities
 freezing cold and full of surly gits.' --- David Damerell