Bug 105386 - -rdynamic -lc_p result in incorrect libraries being used
Summary: -rdynamic -lc_p result in incorrect libraries being used
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
(Show other bugs)
Version: 9
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-09-25 16:25 UTC by Jason Beardsley
Modified: 2007-04-18 16:57 UTC (History)
1 user (show)

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: ---


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

Description Jason Beardsley 2003-09-25 16:25:12 UTC
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 16:26:31 UTC
Created attachment 94722 [details]
Log showing test case

Comment 2 Jakub Jelinek 2003-09-26 14:04:33 UTC
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 19:55:41 UTC
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.