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

[Jeffrey A Law]

  In message < orbtkuipjc.fsf@araguaia.dcc.unicamp.br >you write:
  > On Dec 23, 1998, Jeffrey A Law <law@hurl.cygnus.com> wrote:
  > 
  > >   In message < or3e6bnyme.fsf@araguaia.dcc.unicamp.br >you write:
  > >> On Dec 19, 1998, Jeffrey A Law <law@upchuck.cygnus.com> wrote:
  > 
  > >> 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 i
  > s
  > > not a step forward.
  > 
  > In what sense wouldn't they work?
  > 
I already explained this:

  Consider if you have a shared library that is not bound into the program.  ie
  you load it via shl_load/dl_open.  Call it shlib1.

  For argument's sake, let's pretend shlib1 references __mulsi3.  Let's also
  pretend that neither the main program nor any of the libraries which appear
  on the link line reference __mulsi3.

  Since nothing in the linked executable referenced __mulsi3, __mulsi3 will not
  be a part of the main program's image.

  Now we call shl_load/dl_open to suck in shlib1 to the running executable.  We
  lose because nothing defines __mulsi3 for shlib1 to use.


  > That's why I think controlled symbol exporting is the way to go.  Even
  > if H.J.'s patch won't do the right thing now, it might be fixed,
  > right?
I've got no problems with controlled exporting.  Maybe we're misunderstanding
each other.  I thought you were pushing for not including -lgcc or -lstdc++
again.



jeff