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

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

  In message <orn1x0mbaq.fsf@cupuacu.lsd.dcc.unicamp.br>you write:
  > [Time passes...]
  > 
  > I've just checked libstdc++.so again, and, to my surprise, it is
  > indeed complete.  I don't know what mistake I made when I verified it
  > was not, just before submitting my patch, but now that I see it is
  > indeed complete, I agree the patch I posted is not the way to go.
Weird.  Real weird.


  > 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.

  > 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.  If I had to choose one, it
would be (i).  I believe that is the one with the least amount of problems
(though it runs into the same problems as your suggestion of linking in
all of libgcc.a -- it's a huge binary compatibility issue problem.


  > But wait!  Instead of trying to hide the problem, I tried to find out
  > why it happened.  It turned out that, if I forced certain symbols from
  > libgcc to be copied to libstdc++ (for example, __pure_virtual, used by
  > nest21.C), the multiple-definition errors would stop being flagged!
  > It appears that, when the linker gets to libgcc looking for
  > __pure_virtual, other symbols referred in that object file become
  > `undefined', even though they're present in libstdc++ that had already 
  > been scanned.  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.

  > Fortunately, the work around is straightforward.  Attached is a
  > candidate patch, that has produced good results in initial testing.
  > I'm running check at this very moment, but I have to leave before it
  > finishes, so it may turn out that one or two additional symbols would
  > be needed.  How does this look for 2.95?
Not for gcc-2.95.  There's way too much risk, too many unknowns, etc etc.
No way.  Sorry.  *Maybe* for gcc-2.95.1.  *MAYBE*.

jeff