Bug 105386
| Summary: | -rdynamic -lc_p result in incorrect libraries being used | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Jason Beardsley <jbeardsley> | ||||
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 9 | CC: | mitr | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2003-09-26 14:04:33 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. |
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: