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

[Jeffrey A Law <law at cygnus dot com>]

  In message <ork8s4bhhp.fsf@cupuacu.lsd.dcc.unicamp.br>you write:
  > Anyway, if your position is to recommend static libstdc++, I see no
  > reason to reject my patch, given that it fixes a very serious problem
  > in a configuration that's broken and not recommended anyway, it's
  > platform specific and has minimal impact.  The other option is to
  > change libstdc++/configure.in to completely disable shared library
  > support on OSF, or at least emit large blinking warnings that it's
  > broken, which doesn't seem reasonable to me if there's such a trivial
  > patch that fixes the problem.
Sorry.  This is not going into this release.  First and foremost, the change is
wrong.  Shared libraries need to be self-contained.  Anything else is not
acceptable.  Thus it is not acceptable to simply remove libgcc from a shared
library link line.

In addition to simply being wrong you'll introduce a new and terrible
incompatibility with previous tools because if someone rebuilds a shared
library, it will now be incomplete and there's a good chance it will not
longer work (and thus break any applications which used that library).

This is nearly identical to all the problems that surfaced when some symbols
were made weak in the EH code in egcs-1.1.2.  It was a complete and total
disaster and we do *NOT* want to repeat it.

What we have to do (not for gcc-2.95) is find a way to prevent shared libraries
from re-exporting symbols they get from libgcc.

This change is not going into gcc-2.95.  No way.  Sorry.

I would recommend writing a suitable entry for the FAQ or installation
instructions which discusses the issues and possible workarounds.

jeff