Shared libraries on DU (affects libg++)

[Jeffrey A Law]

  In message < orpv55agpe.fsf@dcc.unicamp.br >you write:
  > Does anybody remember a problem I reported a while back, about
  > creating shared libraries on DU?
Yup.

  > The problem was that gcc/g++ -shared
  > would link the new library with libgcc/libstdc++, causing it to
  > re-export any symbols it imports from them.
Yup.

  > Then, if two libraries
  > are created like this, and you try to link them together into a single
  > program, you'll get duplicate definitions of the re-exported symbols.
I remember the problem.  But I don't remember precisely why we got dups --

gcc foo.c -lbar -lcom

Where bar and com are shared libraries that were built by gcc -shared and
thus export any libgcc symbols they use.  It seems to me that we shouldn't
be getting symbol redefinitions.

  > I've just found out the magic to avoid this conflict: the linker
  > option -hidden.  It will turn symbols imported from object files and
  > libraries listed after it into internal symbols of the shared library,
  > so that they won't conflict with others.  So, I would suggest that we
  > could arrange for at least libstdc++ to be implicitly linked with this
  > flag, which can then be cancelled with -non_hidden for libgcc and/or
  > crtend.
You might read the linux __register_frame_info thread.  I think it applies
here too.  By not exporting the symbols you're going to create a binary
incompatibility in precisely the same cases that we're having trouble with
under linux.

jeff