repost: libg++ won't build on alphaev56-dec-osf4.0d

[Jeffrey A Law]

  In message < or3e6bnyme.fsf@araguaia.dcc.unicamp.br >you write:
  > On Dec 19, 1998, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
  > 
  > > In general, a shared library need to either:
  > 
  > >   a. Include copies of any stndard libraries (libgcc/libstdc++)  or
  > 
  > >   b. Those libraries need to be built as shared libraries and referenced
  > >   by name in any libraries which use libgcc/libstdc++ routines.
  > 
  > Yep, I know what a shared library *should* be, and that libstdc++
  > *should* contain copies of symbols from libgcc if it uses them.  The
  > problem is that this causes libg++.so to fail to build, because some
  > symbols it uses are found in both libstdc++ and libgcc, and it fails
  > to recognize that those are the same symbols.
Good.  Now find a solution that works within those constraints.  Removing
-lgcc or -lstdc++ is not a fix, it just trades one bug for another.

  > The point is that libstdc++ is a library we build together with egcs.
  > Users of DU4 won't be able to create shared libraries with g++ (or
  > with gcc, explicitly linking libstdc++ and libgcc in): they'll get a
  > symbol redefinition error :-(
And with your solution, they can build libraries that don't work.  That is
not a step forward.

  > IMO, creating libstdc++ in a way that it doesn't include symbols from
  > libgcc is not a major problem, because programs that link with
  > libstdc++ are supposed to link with libgcc too.
No.  This is not acceptable.  I've already explained why.    I will not accept
a patch with removes -lgcc.


  > The right fix for this problem would be to arrange that the symbols
  > imported from libgcc are not exported from libstdc++; maybe doing
  > something similar to what H.J.Lu's been doing for Linux would fix the
  > problem on DU too.
Someone has already stated that HJ's patch was wrong and would cause other
problems.  So I haven't installed it.

jeff