Joel Baker <[EMAIL PROTECTED]> writes:
> That's from the build area... binutils is currently:
>
> binutils 2.13.90.0.4-1 The GNU assembler, ...
> binutils-dev 2.13.90.0.4-1 The GNU binary utilities ...
> binutils-doc 2.13.90.0.4-1 Documentation for the GNU assembler, ...
> binutils-multi 2.13.90.0.4-1 Binary utilities that support multi-arch ...
>
> Compiled from unstable a few days ago, using "gcc version 3.1 20020210
> (Debian experimental)"
So this would indeed indicate that you indeed have support for hidden
symbols in the tools; to double check, please do
readelf -s <builddir>/gcc/crtbeginS.o|grep dso
On Linux, this produces
21: 00000000 0 OBJECT GLOBAL HIDDEN 8 __dso_handle
I'm still confused about your analysis that it is the dynamic linker
that reports not finding the symbol, as you reported the message to
read
> /tmp/Build/gcc-3.2/gcc-3.2-3.2ds0/build/i386-unknown-netbsdelf1.6./libstdc++-v3/src/.libs/libstdc++.so:
> undefined reference to `__dso_handle'
> /tmp/Build/gcc-3.2/gcc-3.2-3.2ds0/build/i386-unknown-netbsdelf1.6./libstdc++-v3/src/.libs/libstdc++.so:
> undefined reference to `__cxa_atexit'
> collect2: ld returned 1 exit status
which suggests that this is a ld(1) error. That does not give a
consistent picture, either - __dso_handle is in crtbegin, and if you
use binutils 2.13.90, then the linker should have no problems in
finding the symbol. Could it be that you either pick up the wrong
crtbegin, or the wrong ld?
Regards,
Martin
