GNOME Bugzilla – Bug 609926
segfault due to weak pthread symbols
Last modified: 2010-08-06 13:34:06 UTC
Created attachment 153770 [details] [review] patch to remove weak symbols libxml2 uses pthreads by default, without adding -lpthread to libs in libxml2.la or libxml2-2.0.pc. Our code (see votca.org) links against libxml2. When linking (with libtool) during build we get that some pthread symbol can not be found. Our code does not use threads at all. Ok, one can work around that by adding -lpthread by hand. But even worse, when building a completely static binary (common practice in HPC business) we get a segmentation fault due to a jump to address 0, in __xmlGlobalInitMutexLock(). This is also clear due to fact that the linker sees no dependency on pthread. The attached patch removes the weak symbols and adds -lpthread to libs -> everything works fine.
Sorry, that's a regression for most uses, and I suggest you ask about the "common practice" of shipping static binaries on Linux because coming from the libc experts there are a lot of problems associated with this practice http://people.redhat.com/drepper/no_static_linking.html Shipping statically linked binaries on Linux is nearly garanteed to hit some problems, you found one with libxml2. But I won't change libxml2 defaults over this, at best make it a configure time option, your patch just suppress it completely so not adequate at all. Daniel
I prefer dynamic linking as well, which is obviously the best solution. However on HPC machines you can not do that, because the binary is compile for the compute nodes which have basically no libraries. I can compile our code statically, if I build libxml without threads (even without the patch). But I still don't see the point why the pthread functions are weak symbols, which is the actual problem. What does it harm if libxml is linked against pthreads (in .so and .la files)?
memory allocation on single threaded apps is way faster than on multithreaded for a number of glibc versions. It does make a difference ! Daniel
I see, so how to proceed here? This there a way to force GNU libtools to link against pthread? Adding -lpthread to LDADD helps to solve the shared linking issue, but it doesn't help for static linking. Any ideas?
Created attachment 154931 [details] test program This is a small test case to see the bug. It builds: -a lib, libinit, which just calls xmlInitParser -two binaries ,a dynamic and a static one The static one will fail, when threads are enabled.
Created attachment 154941 [details] test program Just a better version to avoid some warning.
Comment on attachment 154941 [details] test program Unneeded, simpler case below.
Here is the simplest case I can imagine: $ cat main.c #include <libxml/parser.h> int main(int argc, char **argv) { xmlInitParser(); } $ gcc -static main.c `xml2-config --libs --cflags` -pthread $ ./a.out Segmentation fault
We have switched to expat. It has a better availability on supercomputers (HPC). Here are the important Mercurial changesets of our code, as inspiration for those who have the same problem: <http://code.google.com/p/votca/source/diff?spec=svn.tools.00a27a32fbd62ced04529ef29d4a53ee8de1a48e&repo=tools&r=00a27a32fbd62ced04529ef29d4a53ee8de1a48e&format=side&path=/src/libtools/property.cc> and <http://code.google.com/p/votca/source/diff?spec=svn.csg.04f22799120481a7c84bb8432f5d8500df1685c5&repo=csg&r=04f22799120481a7c84bb8432f5d8500df1685c5&format=side&path=/src/libcsg/modules/io/xmltopologyreader.cc>
Created attachment 167251 [details] [review] patch to fix the thread initial issue Even if we have switched to expat the problem still persists. This issue is tracked under debian bug #590934: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590934 and there is a patch to solve the issue by moving xmlInitThreads() The patch works for me!