Bug 114738 - load fail on hidden symbol `__dso_handle'
Summary: load fail on hidden symbol `__dso_handle'
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: libaio (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: All Linux
high
high
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-02-02 07:39 UTC by Ralph Menikoff
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-17 17:23:38 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)
tar file of simple source to reproduce __dso_handle error (10.00 KB, application/tar)
2004-02-16 04:19 UTC, Ralph Menikoff
no flags Details

Description Ralph Menikoff 2004-02-02 07:39:48 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922

Description of problem:
Linking with shared object fails with message
 hidden symbol `__dso_handle' in
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/crtbegin.o is referenced by DSO
Probably same as bug #109457
Tried to uninstall libaio but rpm said it wasn't installed
despite being in /usr/lib
Didn't understand patch listed under #109457
I don't need libaio can I remove it 
or is there a workaround ?

Version-Release number of selected component (if applicable):
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24)

How reproducible:
Always

Steps to Reproduce:
1. I have not yet simplified code because it seems like previous
verified severe error.  
2.
3.
    

Actual Results:  load error

Expected Results:  expect to produce executable

Additional info:

On older system with RH Linux 7.1 with gcc 3.2.3 installed
the code links and runs.  This is problem with system libraries

Comment 1 Ralph Menikoff 2004-02-06 04:07:42 UTC
A colleague of mine, James Quirk, had previously come across this bug
and gave me a workaround.
I had made shared object using g++ and tried to link shared object
into execuatble using g++.  I can get this to work if I compile object
with 1 line
void* __dso_handle;
and link it with shared object.
Then g++ makes executable without error.
I was mistaken that my problem was related to previous bug #109457
But that is only reponse I got from bugzilla querry for dso_handle.
google search gives slew of comments related to dso_handle problems.
When is this bug going to be fixed ?

Comment 2 Jeff Moyer 2004-02-12 17:18:33 UTC
Please provide a reproducer.

Comment 3 Ralph Menikoff 2004-02-16 04:19:49 UTC
Created attachment 97695 [details]
tar file of simple source to reproduce __dso_handle error

tar xvf dso_bug.tar
make Main
gives error 
/usr/bin/ld: Main: hidden symbol `__dso_handle' in
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/crtbegin.o is referenced by DSO
Variation make Work; ./Work # runs fine
The line that cause ld problem is #include <iostream> in source Hello.C for
shared object.

Comment 4 Jakub Jelinek 2004-02-17 17:23:38 UTC
Your testcase is broken.
Never ever use ld -shared, always use gcc -shared or g++ -shared,
it knows the details how to build correct shared libraries unlike your
makefile.


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