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: Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Subject: Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 02 Aug 1999 01:47:39 -0600
- cc: Richard Henderson <rth at cygnus dot com>, egcs-bugs at egcs dot cygnus dot com, egcs-patches at egcs dot cygnus dot com
- Reply-To: law at cygnus dot com
In message <orr9mav362.fsf@cupuacu.lsd.dcc.unicamp.br>you write:
> >> 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.
I spoke with Jason about this stuff while I was in Sunnyvale a couple weeks
ago.
He thinks we just have to bite the bullet and go with a shared libgcc.
So we need to start thinking in that direction across all the targets where we
support building shared libraries.
Among other things this means:
* We will want to move libgcc out of $libsubdir and put it in $libdir
* We will need to have a version #-ing scheme. We may (or may not)
need something like HJ's interface patch for libgcc
* We need some reasonable way to describe how to build shlibs that
we can use across gcc, libstdc++, libiberty, etc etc.
I'm sure there's a bunch of other issues we're going to need to tackle, but we
can at least start thinking about them and moving in the right direction.
I stronly doubt we'll fix this for the gcc-2.95 minor releases, but it would
be good to fix it for the next major release.
jeff