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 12/6/05, Nix <nix@esperi.org.uk> wrote:
> 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
>
>

Thanks for the good info.  I tried LD_DEBUG=libs and it shows (exert):
trying file=/lib/tls/libpthread.so.0
trying file=/lib/libpthread.so

So it seems to not like the contents of /lib/tls/libpthread.so.0.  I
think it *must* be the cpu because when I run it on my laptop (same
libraries, same gcc, same kernel) it works fine and uses NPTL.  The
cpu is the only thing that is different!


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