Description of problem:
A C program linked with '-rdynamic' and the profiled libc (-lc_p) does not use
the correct libraries in /lib/tls (e.g. /lib/tls/libc.so), but instead uses
their counterparts in /lib. Either flag by itself is fine, the combination is not.
As a result, while the program will run, if it attempts to dlopen() a shared
library (e.g. a Python extension module), it will crash.
Version-Release number of selected component (if applicable):
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
How reproducible: 100%
Steps to Reproduce:
1. Compile a trivial C program using -rdynamic and -lc_p on the link line.
2. ldd it
3. Note the libraries used (and the 'Incorrectly build binary...' warning)
Created attachment 94722 [details]
Log showing test case
libc_p is only provided as .a library, not as a shared library.
So if you want to profile (other than using oprofile/valgrind etc.),
you need to link statically.
Linking against both libc_p.a and libc.so is a user bug.
You shouldn't link against -lc_p by hand anyway, instead use -profile gcc switch.
My application has an embedded Python interpreter, which dynamically loads
extension modules at runtime. It cannot be linked statically. So what you are
saying is that I cannot profile the program (at least, not fully - I can't link
with the profiled C library, but thankfully I am able to use '-pg' to profile my
Interesting, because I was able to do just that on RH8, even if this was not the
proscribed manner in which to profile using gprof.