Bug 105386 - -rdynamic -lc_p result in incorrect libraries being used
-rdynamic -lc_p result in incorrect libraries being used
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-25 12:25 EDT by Jason Beardsley
Modified: 2007-04-18 12:57 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-26 10:04:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Log showing test case (1.33 KB, text/plain)
2003-09-25 12:26 EDT, Jason Beardsley
no flags Details

  None (edit)
Description Jason Beardsley 2003-09-25 12:25:12 EDT
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:
Comment 1 Jason Beardsley 2003-09-25 12:26:31 EDT
Created attachment 94722 [details]
Log showing test case
Comment 2 Jakub Jelinek 2003-09-26 10:04:33 EDT
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.
Comment 3 Jason Beardsley 2003-09-26 15:55:41 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.