Description of problem: I really dislike filing this report because I feel that the problem is not with glibc but ... that is the only place I can find. The program involved is "partimage" and it very large. The system is FC4 with current maintenance ... specifically glibc-2.3.5-10.3 As I use partimage, the executable is created in both with dynamically linked and completely statically linked versions. partimage uses pthreads to create an extra thread to write debugging info to a file (it uses pthreads in other places but they are not invoked as I use the program). When I run the dynamically linked executable, everything works OK. When I run the statically linked executable, I get a segmentation fault which I have narrowed down to the execution of pthread_mutex_init(...) I have a coredump with the problem (repeatable, can create on demand). I have tried running the program with gdb but I get: Starting program: /home/devel/rpmbuild/BUILD/partimage-0.6/src/client/partimage Reading symbols from shared object read from target memory...done. [Thread debugging using libthread_db enabled] Cannot find new threads: generic error Cannot find user-level thread for LWP 8827: generic error If this is another bug I will report it separately. Any hints as to the problem would be greatly appreciated. Any hints as to how to get more info would also be appreciated. BTW, this worked fine with FC3 and the "old" threads code. I have also used the thread examples from glibc and statically linked them but they work fine.
OK, I have finally determined that the function call to pthread_mutex_init() is not being resolved (it is "call 0x0" in the ddd disassembly) ... yes, I figured out how to get gdb/ddd to work inspite of the "error" ... simply continue. Here is the static link command as original: g++ -Wall -g -O2 -o partimage -static netclient.o imagefile.o misc.o image_net.o buffer.o gui_text.o main.o imginfo.o cbitmap.o interface_base.o interface_newt.o interface_none.o mbr_backup.o -L/usr/local/lib -lslang fs/libfs.a ../shared/libshared.a -lz -lnewt -lbz2 -lpthread /usr/lib/libslang.a /usr/lib/libnewt.a /usr/lib/libdl.a /usr/lib/libpthread.a did not work. I then tried this: g++ -Wall -g -O2 -o partimage -static netclient.o imagefile.o misc.o image_net.o buffer.o gui_text.o main.o imginfo.o cbitmap.o interface_base.o interface_newt.o interface_none.o mbr_backup.o -L/usr/local/lib -lslang fs/libfs.a ../shared/libshared.a -lz -lnewt -lbz2 /usr/lib/libslang.a /usr/lib/libnewt.a /usr/lib/libdl.a /usr/lib/libpthread.a /usr/lib/libpthread_nonshared.a again, it did not work. I then built )compiled) the glibc from the src.rpm and copied glibc-20050524T1606/build-i486-linuxnptl/nptl/pthread_mutex_init.o to the directory with my progam and did this: g++ -Wall -g -O2 -o partimage -static netclient.o imagefile.o misc.o image_net.o buffer.o gui_text.o main.o imginfo.o cbitmap.o interface_base.o interface_newt.o interface_none.o mbr_backup.o pthread_mutex_init.o -L/usr/local/lib -lslang fs/libfs.a ../shared/libshared.a -lz -lnewt -lbz2 /usr/lib/libslang.a /usr/lib/libnewt.a /usr/lib/libdl.a /usr/lib/libpthread.a /usr/lib/libpthread_nonshared.a This worked! The program executed with (apparently) the other ptheread function calls being resolved. Stepping through the programs execution with ddd, this time the call I saw was resolved to "call pthread_mutex_init" rather tha "call 0x0" Now this may have worked but it is not a fix. Any hints as to what I am doing wrong?
OK, as an additional test, I hacked up the Makefiles to use /usr/include/linuxthreads headers and /usr/lib/linuxthreads libraries. This works with no problems.
Mmmm ... this does appear to be a dup of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=115157
Since everything seems to work OK using (the old) linuxthreads and it has "#pragma weak" also specified, why does this work and the ntpl does not?
*** This bug has been marked as a duplicate of 115157 ***
After spending lots of time (about three days) trying to figure out what the pthread (segfault) problem was [it took a while until I understood that the function call had not been resolved when it was statically linked], I find that it was a waste of time [well, I did learn a bit about "weak" linkage]. As I said above, the problem was with statically linked partimage which was statically linked so that I did not need to worry about extra libraries when I ran it under the rescuecd. Well, I need not have worried, the shared linked version runs just fine under the rescuecd ... all the needed libraries (newt, slang, bz2, z, AND pthread) where there. At least not I do not have to wait for Alexandre's fix to work its way into production.