Red Hat Bugzilla – Bug 20482
Differences between static and dynamic ptherad libraries
Last modified: 2016-11-24 10:23:34 EST
I've noticed a difference between the static and dynamic versions of
the pthread library.
It appears that the statically linked version behaves normally. The
dynamically linked version stops executing the application when two
threads are waiting to lock the same mutex. Execution never
resumes to the thread that has the mutex locked.
The only difference between the two during the make is using the -
static linker option. The dynamic version of the program is linked to
libldap.so.1 => /usr/lib/libldap.so.1 (0x40023000)
liblber.so.1 => /usr/lib/liblber.so.1 (0x40039000)
libpthread.so.0 => /lib/libpthread.so.0 (0x4003f000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
libm.so.6 => /lib/libm.so.6 (0x40098000)
libc.so.6 => /lib/libc.so.6 (0x400b8000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Another problem that I noticed between the dynamic and static
versions is that gdb will report many warnings when I try to debug the
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License,
and you are
welcome to change it and/or distribute copies of it under certain
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
This GDB was configured as "i386-redhat-linux"...rw_common ():
write: Function not implemented.
warning: unable to set global thread event mask
[New Thread 1024 (active)]
rw_common (): write: Function not implemented.
warning: stop_or_attach_thread: generic error
And consequently debugging multithreaded apps is nearly
impossible, since the debugger can no longer switch between
threads or even list them with "info threads". I do not get these
messages with the dynamically linked version of my binary.
I've since upgraded the glibc libraries from the 7.0 support/upgrade
pages hoping that they would fix my problem. Here is rpm -qa | grep
Intially this was a RH 6.2 box and there were no differences between
a statically or dynamically linked binary (executing behavior that is). I
upgraded using the 2 cds out of the 7.0 box with the upgrade
procedure. Initially, 6.2 was installed using custom/install everything.
I recently rpm -e compat* packages to ensure that they were not
causing my problems; no change.
I checked my source out of cvs on another RH box, a 6.0 one, and the
binaries work the same statically or dynamically linked. Also gdb
functions correctly with both binaries.
The same source also compiles and runs correctly on several other
unixes including solaris 2.7, and MacOS X.
All binaries are built using the -g gcc/g++ option.
I've verified my gcc/glibc packages with -V.
This problem is definitely new with 7.0.
By any change, aren't the threads locking in endl or ends C++
iostream functions? That was a bug in libstdc++ which has been fixed
If not, can you either put up a testcase where it locks up when
dynamically linked or give me access to your program including
instructions how to reproduce it?
Created attachment 5140 [details]
a simple multithreaded program with mutexes
g++ -g -static -o testmutex_static testmutex.cpp -lpthread
g++ -g -o testmutex testmutex.cpp -lpthread
Your right, looks like it is endl causing the problems only in a dynamically
Execution stops after Thread C prints it output in the dynamically linked
However, the gdb issues are visible in the statically linked binary.
(gdb) break threadB
The current thread is the wrong one, and there is no list of threads (info
threads). So you cannot switch to the right one.
In the interest of completeness... I made another simple single threaded
app that used endl. No problems either dynamically or statically linked.
Also no problems with gdb. This app did not include the pthread library,
which would be the only difference.
Please try libstdc++*2.96-6[0-3].*.rpm in rawhide (dunno which release is
there currently), it should be fixed in there.
AFAIK gdb support for threads is for dynamically linked apps only.
What is the path for this rpm on the ftp server? I've checked updates/7.0/
ix86/, and nothing. Also, current/i386/RedHat/RPMS has the same one I
I'm unaware of any limitations of gdb on statically linked binaries, as I've
been using gdb on statically linked binaries in the past (including on RH
6.2). It's only recently started having problems as of RH 7.0.
The rpms are in rawhide currently, which is ftp.redhat.com/rawhide/i386/
As far as debugging statically linked threaded programs goes, you're
right that it somehow (although pretty badly) worked in 6.2, but the
code for handling threads is completely new in gdb 5.x.
If you confirm that the first bug is fixed by libstdc++ from rawhide,
I'll reassign this bug to gdb.
I'm using RH7.1 (kernel 2.4.2-2) and find gdb (--version: GNU gdb 5.0rh-5 Red
Hat Linux 7.1) can't debug any multi-threaded apps because the pthreads library
was shipped as stripped:
/lib/libpthread-0.9.so: ELF 32-bit LSB shared object, Intel 80386, version 1,
Mandrake 7.x (?) has this same problem. Don't strip these libraries!
Unless you have LD_ASSUME_KERNEL=2.2.5 set in environment or
unless you actually run kernel earlier than 2.4.1, this library is
not used (and as this is not the common case, I think it is much better
to have this stripped than not stripped):
file /lib/libpthread-0.9.so /lib/i686/libpthread-0.9.so
/lib/libpthread-0.9.so: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped
/lib/i686/libpthread-0.9.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped
I cannot reproduce any problem. Your test case works fine on a RHL9 system. If
you still have problems please open a new bug.