shared libstdc++ is broken on alphaev56-dec-osf4.0d

Alexandre Oliva oliva@dcc.unicamp.br
Sat Jul 10 01:49:00 GMT 1999


On Jul  6, 1999, Richard Henderson <rth@cygnus.com> wrote:

> On Mon, Jul 05, 1999 at 10:52:02AM -0300, Alexandre Oliva wrote:
>> Richard, it seems that the following patch broke shared library
>> construction on alpha-dec-osf4.0:
>> 
>> Mon Jun 21 20:10:42 1999  Richard Henderson  <rth@cygnus.com>
>> 
>> * collect2.c (main): Log frame table count.
>> (GCC_OK_SYMBOL) [ECOFF]: Accept stGlobal.
>> (scan_prog_file) [COFF]: Handle frame tables.

> Without this patch, absolutely no EH works, staticly linked
> or otherwise.

I see...

>> FAIL: g++.brendan/nest21.C (test for excess errors)
>> /usr/bin/ld:
>> /usr/local/tmp/egcs/gcc/libgcc.a(_eh.o): \
>> _GLOBAL_$F$__default_terminate: multiply defined

> So we need to somehow prevent libgcc symbols from being exported
> from the shared library.  I don't know DU well enough to know if
> that's possible.

It is.  I've just been able to build a shared libstdc++ that passes
all tests by appending: 

'-Wl,-hidden_symbol,__throw,-hidden_symbol,__register_frame_info_table,-hidden_symbol,__deregister_frame_info,-hidden_symbol,_GLOBAL_$$F$$__default_terminate'

to libstdc++/config/dec-osf.ml's SHDEPS.

However, I recall Jeff having discussed with me the issue of hiding
symbols in a shared library, and he convinced me it was not the way to
go, because functions within the shared library would refer to the
internal, hidden symbol, whereas functions in other libraries would
refer to the symbols from libgcc, which would not be unified with the
hidden ones, so things would break.

Anyway, I've just noticed that our current libstdc++ build produces
the following warning while linking the shared libstdc++:

/usr/bin/ld:
Warning: Unresolved:
__throw

I don't understand why this happens, but it is indeed true that
libstdc++ does not have a definition for __throw:

oliva@bela% nm libstdc++.so | grep __throw
                 U __throw
000003ffbff91190 T __throw_bad_cast
000003ffbff91550 T __throw_bad_typeid
000003ffbff94930 T __throw_type_match
000003ffbff94cd0 T __throw_type_match_rtti

Since AFAIK the only reason to link libgcc into the shared libstdc++
is to ensure that it's complete, so that it can be dlopened, but this
is not currently accomplished, I suggest that we simply stop linking
libstdc++ with libgcc, so that we can at least release gcc 2.95 with a
working shared libstdc++ on alpha-dec-osf4.0d, and then we can worry
about the symbol exporting problem later.

Jeff, is this ok for the release branch?  (Maybe for mainline too?)

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{guarana.com,{gnu,kaffe,samba}.org,{egcs,sourceware}.cygnus.com}
*** E-mail about software projects will be forwarded to mailing lists


More information about the Gcc-bugs mailing list