FYI: shared libs and iostream (C++)

ta0kira · 06-07-2005, 01:47 AM

If you ever get an error loading a shared lib you've written which uses iostream that tells you that __dso_handle is undefined (display dlerror after attempting to load), just add the following to your main lib file:

Code:

extern "C"
{
void *__dso_handle = NULL;
}

This took me several hours to figure out since I could not find a solution on the internet. __dso_handle is declared in the standard iostream header for gcc, however when linking shared libs it doesn't seem to link. It will link in executables however. I tried linking the lib with libstdc++.a/.so, but that doesn't link it either. In gcc 4.0.0 it is defined in libstdc++.a (you can see it by typing `nm libstdc++.a` from the lib path), but it will not link into the lib. Since the variable contains "handle", I figured it was a void*, therefore I declared that in the lib, which luckily worked. If you would like to see exactly where in your includes __dso_handle is declared, add the following line at the beginning of a file with iostream included (before the includes):

Code:

extern int __dso_handle;

This will cause a compiler error at the location where it is declared because of the differing type. That is how I found exactly where it is. In my iostream header it is declared as static, therefore I tried compiling after removing the static identifier from the declaration, which also did not work. Another thing I tried was using stdio.h instead, but I had the same problem.
Anyway, just thought I would let you all know since I did not see anything anywhere that gave a solution to the problem.
ta0kira

freegianghu · 06-07-2005, 01:59 AM

Quote:

GCJ FAQ
4.7 I'm getting 'undefined symbol: __dso_handle'

Some versions of the GNU linker have broken support for the '.hidden' directive, which results in problems with shared libraries built with recent versions of gcc.

There are three solutions:

* downgrade to binutils that don't support .hidden at all,
* upgrade to a recent binutils, or
* undef the HAVE_GAS_HIDDEN definition in gcc's auto-host.h (and rebuild gcc).

ta0kira · 06-07-2005, 02:56 AM

Thanks. I wonder why that's in Java help.
ta0kira

ta0kira · 06-09-2005, 11:08 AM

I tried the second 2; upgraded to binutils 2.16, and remade gcc after commenting out HAVE_GAS_HIDDEN. Neither worked. Anyone have a solution that worked? Thanks.
ta0kira

freegianghu · 06-09-2005, 11:55 AM

Quote:

Originally posted by ta0kira
I tried the second 2; upgraded to binutils 2.16, and remade gcc after commenting out HAVE_GAS_HIDDEN. Neither worked. Anyone have a solution that worked? Thanks.
ta0kira

If you are using gcc-2.9, try apply with LFS patch and rebuild gcc?

Good luck,
GH

ta0kira · 06-09-2005, 03:45 PM

Using gcc 4.0.0. That patch should already be incorporated then, right? The thing with auto-host.h is that you have to make once for it to show up, then edit it, then remake, then make install. The docs say that it is generated by ./configure, but it's really generated by make. Maybe that is where the problem is. I really think the problem is with the linker because the only time I get the error is when using ld (even with a regular executable).
ta0kira

freegianghu · 06-09-2005, 08:50 PM

Quote:

Originally posted by ta0kira
Using gcc 4.0.0. That patch should already be incorporated then, right? The thing with auto-host.h is that you have to make once for it to show up, then edit it, then remake, then make install. The docs say that it is generated by ./configure, but it's really generated by make. Maybe that is where the problem is. I really think the problem is with the linker because the only time I get the error is when using ld (even with a regular executable).
ta0kira

May be your linker did not link to right crtbegin.o (ex: /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/crtbegin.o)

Just a thought,
GH

ta0kira · 06-10-2005, 03:25 AM

At what point in the process are you talking about? Thanks.
ta0kira

freegianghu · 06-10-2005, 05:32 AM

Quote:

Originally posted by ta0kira
At what point in the process are you talking about? Thanks.
ta0kira

I write small test (test.cpp):

Code:

#include <iostream>
using namespace std;
int main(int argc, char *argv[])
{
    cout << "Hello, world" << endl;
}

Then run:

Code:

# g++ main.cpp -o mytest
# nm mytest | grep dso_handle
08049bac D __dso_handle

My box:

Code:

 
# ld -v
GNU ld version 2.16.90.0.3 20050510
# /lib/libc-2.3.5.so
GNU C Library stable release version 2.3.5, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.4.
Compiled on a Linux 2.6.11 system on 2005-05-24.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.
# gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/usr/local --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++
Thread model: posix
gcc version 4.0.0

Could you try again on your box? Your g++ may has problem, I think.

Cheers,
GH

Edit: when I run
# nm libstdc++.a | grep dso_handle
U __dso_handle
(__dso_handle is external variable, that why you can not link with)

ta0kira · 06-10-2005, 03:11 PM

That works, but here is my situation:

Code:

g++ -c -o mytest.o main.cpp
ld -o mytest -lstdc++ mytest.o

Which leaves __dso_handle undefined (with gcc 3.3.4 and 4.0.0 and ld 2.15.x and 2.16). Thanks.
ta0kira

ta0kira · 06-10-2005, 08:12 PM

I guess the real questions is: what is g++ telling ld that I'm NOT telling it? Do you know how to find that out? Since I only have the problem when I separate linking from g++, if I could find out exactly what g++ passes to the linker then I should be able to duplicate that. BTW I even have this problem with the Slackware 10.0 binaries of ld and g++.
ta0kira

freegianghu · 06-10-2005, 09:03 PM

Quote:

Originally posted by ta0kira
I guess the real questions is: what is g++ telling ld that I'm NOT telling it? Do you know how to find that out? Since I only have the problem when I separate linking from g++, if I could find out exactly what g++ passes to the linker then I should be able to duplicate that. BTW I even have this problem with the Slackware 10.0 binaries of ld and g++.
ta0kira

Hi ta0kira, I've found an answer here. (Use gcc -v for verbose)

Hope this helps,
GH

ta0kira · 06-10-2005, 10:14 PM

Thanks. I'll try it. Can you build your test with the 2 command lines I posted before to see if you get the undefined reference to __dso_handle? Thanks.
ta0kira

freegianghu · 06-10-2005, 10:44 PM

Quote:

Originally posted by ta0kira
Thanks. I'll try it. Can you build your test with the 2 command lines I posted before to see if you get the undefined reference to __dso_handle? Thanks.
ta0kira

Mine is:

Code:

# g++ -v -c -o mytest.o main.cpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/usr/local --libexecdir=/usr/li
b --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=
gnu --enable-languages=c,c++
Thread model: posix
gcc version 4.0.0
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -quiet -v -D_GNU_SOURCE main.cpp -
quiet -dumpbase main.cpp -mtune=pentiumpro -auxbase-strip mytest.o -version -o /
tmp/cc1AkgBW.s
ignoring nonexistent directory "/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../..
/../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-p
c-linux-gnu
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backwa
rd
 /usr/local/include
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/include
End of search list.
GNU C++ version 4.0.0 (i686-pc-linux-gnu)
        compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32075
 as -V -Qy -o mytest.o /tmp/cc1AkgBW.s
GNU assembler version 2.16.90.0.3 (i686-pc-linux-gnu) using BFD version 2.16.90.
0.3 20050510

# ld -o mytest -lstdc++ mytest.o
ld: warning: cannot find entry symbol _start; defaulting to 08048410 // did it make problem?
mytest.o: In function `__static_initialization_and_destruction_0(int, int)':
main.cpp:(.text+0x87): undefined reference to `__dso_handle'

Other:

Code:

# g++ -v -o mytest main.cpp
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/usr/local --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++
Thread model: posix
gcc version 4.0.0
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -quiet -v -D_GNU_SOURCE main.cpp -quiet -dumpbase main.cpp -mtune=pentiumpro -auxbase main -version -o /tmp/ccEYh7E9.s
ignoring nonexistent directory "/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backward
 /usr/local/include
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/include
 /usr/include
End of search list.
GNU C++ version 4.0.0 (i686-pc-linux-gnu)
        compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32075
 as -V -Qy -o /tmp/ccTqOOtB.o /tmp/ccEYh7E9.s
GNU assembler version 2.16.90.0.3 (i686-pc-linux-gnu) using BFD version 2.16.90.0.3 20050510
 /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o mytest /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/crtbegin.o -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0 -L/usr/lib/gcc/i686-pc-linux-gnu/4.0.0 -L/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../.. /tmp/ccTqOOtB.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/crtend.o /usr/lib/crtn.o

ta0kira · 06-11-2005, 12:16 AM

From what I can remember those are my exact results. I see several flags in the `collect2` line that I didn't use for ld. I know collect2 is ld by typing `./collect2 --help`; that gives ld as the title. Glad to hear (?) you have the same problem. That means I need to use some different flags or `-l`s. Thanks.
ta0kira