Re: __register_frame_info & shared library compatibility

[Jeffrey A Law <law@upchuck.cygnus.com>]

  In message < 199904121315.JAA13984@blastula.phys.columbia.edu >you write:
  > >True.  But we've made not attempt to make that setup work and have no
  > >intention of making that setup work.
  > 
  > You may not have, but Mark, HJ, Ulrich and I spent about a month
  > trying to fix exactly this setup.  The conclusion was that the patch
  > you don't like was the best solution.
The egcs project has never considered this kind of compatibility with
gcc-2.7 compiled binaries a priority.

Giving up compatibility with egcs itself to achieve compatibility with
an outdated, pre-EH compiler from the FSF is not acceptable.  Sorry.

  > 
  > >But it is unacceptable when a library that was originally compiled
  > >with egcs-1.1.1, after compiling with egcs-1.1.2 to cause libraries
  > >to stop working.  Plain and simple, it is unacceptable.
  > 
  > The library should not have been compiled with egcs 1.1.1 in the first
  > place.
  > 
  > Yes, I realize this is an unrealistic attitude.  Would you at least
  > consider an -mcompat-1.0 switch?
The default must be to be compatible with prior egcs releases.  I'd much
prefer not add a switch to enable the losing behavior because it just adds
to the long term maintenance and confusion.


  > # When I compile glibc 2.0.{6,7} with egcs, glibc ends up defining the
  > # symbols __register_frame_info & __deregister_frame_info. I noticed
  > # that these are also defined in egcs' libgcc.a Should this be
  > # happening?
  > #
  > # The real problem happens when I upgrade to a glibc that was not
  > # built with egcs.  Some of the programs I compiled with egcs under a
  > # egcs built glibc also have a dependency on these symbols.  If it
  > # wasn't /bin/login, I might not have cared so much. :-/
  > 
  > Please note the wording: "upgrade to a glibc that was not built with
  > egcs".  As long as the official libc binaries shipped by the
  > distributions are built by gcc 2.7, egcs MUST match gcc 2.7's ABI for
  > C programs.  That is what the patch achieves.  And we told the
  > distributions to use gcc 2.7 until they switch to glibc 2.1, so this
  > will continue to be a problem.
OK.  This kind of compatibility is not a priority and never has been.  We've
always known this would not work.

If you can find a solution that works in both worlds, then great.  But I do
not believe one exists.  And in the absence of a perfect solution we must
continue be compatible with our own releases over compatibility with gcc-2.7.

At this point I'm still planning to remove the patch and make an egcs-1.1.3
release.

jeff