Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 114738 - load fail on hidden symbol `__dso_handle'
load fail on hidden symbol `__dso_handle'
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: libaio (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Jeff Moyer
Depends On:
  Show dependency treegraph
Reported: 2004-02-02 02:39 EST by Ralph Menikoff
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-17 12:23:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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-15 23:19 EST, Ralph Menikoff
no flags Details

  None (edit)
Description Ralph Menikoff 2004-02-02 02:39:48 EST
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:

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

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-05 23:07:42 EST
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 12:18:33 EST
Please provide a reproducer.
Comment 3 Ralph Menikoff 2004-02-15 23:19:49 EST
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 12:23:38 EST
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

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