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

[Alexandre Oliva <oliva at dcc dot unicamp dot br>]

On Jul 14, 1999, Jeffrey A Law <law@cygnus.com> wrote:

>> How about linking the entire libgcc.a into libstdc++.so, with `-all
>> -lgcc', so that g++ doesn't explicitly link with -lgcc?  Would that be 
>> reasonable for 2.95.1?

> Ewww.  Actually, this is bad too since all code which uses libstdc++
> will then expect libstdc++ to provide all symbols from libgcc.
> Later if we fix the problem we're going to gratuitiously break lots
> of code that did not get its own copy of any libgcc routines because
> libstdc++ had all of libgcc and exported everything.

I see...  That's a good reason for not installing the patch for gcc
2.95, unless we'd promise not to change it in the future.

FYI, the last patch I posted was indeed incomplete: delete3.C still
complained about some duplicate symbols in libgcc's new.o, _eh.o and
exception.o.  If I come up with a solution, be it
`-Wl,-all,-lgcc,-none' or
`-Wl,-u,__some_symbol,-u,__some_other_symbol,...', may I mention it in
the specific.html web page, along with the possible negative
consequences of it?

>> AFAICT, there are only three ways to prevent this: (i) link with
>> `-hidden -lgcc', so that symbols from libgcc are made local to the
>> shared library; this is a problem because then we can have multiple
>> separate definitions of the same symbols; or (ii) arrange that libgcc
>> is shared, so that symbols are not copied, but libstdc++ is noted to
>> depend on libgcc; I know there are reasons to prefer not to do it.  So 
>> I don't see any way out :-(

> It really is a *(&@#$)(* mess and no matter what you do, you're just
> going to trade one set of bugs for another.  Thus my reluctance to
> do anything since no solution is clearly better than the others.

Actually, I wrote that before confirming what I had believed from the
beginning, which is that DU's ld actually *does* ignore duplicate
definitions when they're the same, but it fails to do so in some cases
because of a bug.  So I don't think we should care about this problem
any more.

>> But then, when it finds the symbols in libgcc.a, it ``remembers''
>> they were already defined in libstdc++.so, and reports them as
>> duplicates.  A linker bug.  :-(

> Then let's report it to dec/compaq/whomever, get it fixed and avoid the
> issues entirely instead of trying to hack around it.

Yup, I'll try to get a small test case, but I don't have any official
contact for bug reporting within dec/compaq/whomever, does anybody?

>> How does this look for 2.95?

> Not for gcc-2.95.  There's way too much risk, too many unknowns, etc etc.

Yup, I see.  It's easy to overlook something when desperately trying
to fix a problem :-)

It's very good to have someone as careful as you leading the project.
Thanks, Jeff! :-)

> *Maybe* for gcc-2.95.1.  *MAYBE*.

When I find a reduced testcase, if it's small enough, I may try to
come up with an autoconf test to detect the bug and enable the
work-around, or simply to disable or just warn about the shared
libstdc++ problem, if you think it's worth it.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them