This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d
- To: law at cygnus dot com
- Subject: Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d
- From: Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Date: 13 Jul 1999 00:50:59 -0300
- Cc: Richard Henderson <rth at cygnus dot com>, egcs-bugs at egcs dot cygnus dot com, egcs-patches at egcs dot cygnus dot com
- References: <635.931650096@upchuck.cygnus.com>
On Jul 10, 1999, Jeffrey A Law <law@cygnus.com> wrote:
> In message <orwvw8khxu.fsf@cupuacu.lsd.dcc.unicamp.br>you write:
>> 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?)
> No. I don't want to make this change, particularly this late in the
> cycle. We're just exchanging one set of known problems for a set of
> unknown problems.
But a *very serious* set of known problems. The way it is now,
libstdc++ on OSF4/alpha is useless for any non-trivial C++ program.
:-(
Another option would be to link libgcc into libstdc++.so with -all (so
that all objects of libgcc are copied into the shared library), and
arrange that g++ doesn't link with -lgcc in addition to -lstdc++. But
IMHO this would be much more dangerous than the very simple
work-around I'm suggesting.
--
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