Hide Forgot
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) glibc-2.3.2-27.9 glibc-devel-2.3.2-27.9 glibc-common-2.3.2-27.9 glibc-profile-2.3.2-27.9 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) Actual results: Expected results: Additional info:
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 own code). 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.