This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Strange linking problem (MIPS, n32): wrong version node for libpthread!
- From: "Kaz Kylheku" <kaz at zeugmasystems dot com>
- To: <libc-ports at sourceware dot org>
- Date: Wed, 26 Dec 2007 23:41:23 -0800
- Subject: Strange linking problem (MIPS, n32): wrong version node for libpthread!
Hi Everyone,
I've discovered a silly problem on (MIPS, n32 ABI, gcc 4.1.1, glibc 2.5,
binutils 2.17, ...).
I have a shared library which calls pthread functions. It is linked
with -pthread. However, this -pthread is not enough to actually link it to
libpthread.so. If you run ``ldd'' on the library image, libpthread is not
mentioned anywhere!
This is very sneaky. We've been developing a very large and complex
application for quite a long time, and the problem has gone unnoticed. The
system runs, passes QA tests, etc.
What happens is that because the library doesn't depend on libpthread.so as
it should, it doesn't request the appropriate symbol version node. Its
references to pthread somehow get resolved to GLIBC_2.0.
So for instance pthread_create doesn't go to __pthread_create_2_1 but to
__pthread_create_2_0. And this means that the stack size attribute set up in
the pthread_attr_t parameter is ignored! So the virtual memory footprint of
the application suite is far larger than what it should be due to all the
threads mmap'ping the default 8 megs of stack.
If you add -lpthread when linking the library, it fixes the problem. (I've
verified it in a small repro program, not the real app, but it's obvious it
should work).
But this -lpthread should not be necessary if -pthread is already there,
should it? It's a hack workaround.
This is probably in the wrong mailing list, sorry folks. Happy New Year,
etc.