GCC 3.0 Release Criteria

[Jeffrey A Law]

  In message < 20000427150244.B14210@wolery.cumb.org >you write:
  > On Thu, Apr 27, 2000 at 02:03:59PM -0700, Geoff Keating wrote:
  > > > 
  > > > Assume libfoo.so links against libgcc.a, includes a half-dozen function
  > s
  > > > (most notably __register_frame_info and company) and re-exports them.
  > > 
  > > Actually, this doesn't happen for __register_frame_info under linux:
  > > 
  > > 00000000  w   DF *UND*  000000e4  GLIBC_2.1.3 __cxa_finalize
  > > 00000000  w   DF *UND*  000000f0  GLIBC_2.0   __deregister_frame_info
  > > 00000000  w   DF *UND*  000000a8  GLIBC_2.0   __register_frame_info
  > > 
  > > I don't understand why, it's something to do with their being exported
  > > from libc.so.
  > 
  > The frame functions are forcibly sucked into libc.so and reexported in
  > order to prevent exactly the problem Richard describes.  Or maybe I
  > should say to prevent it from happening _again_, because it already
  > happened in real life, around glibc-2.0.6.  Look at the libc-hacker
  > archives for Nov 1998-Mar 1999, I think.
Right.  But these same kinds of problems happen on systems where we do not
control libc -- so we don't have the options of forcing them into libc.so
to avoid this problem.

jeff