Re: __register_frame_info & shared library compatibility

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

  In message <19990406170202.J29505@moebius.dartmouth.edu>you write:
  >  Object      Soname           Compiler
  >  ------      ------           --------
  >  glibc 2.0   libc.so.6        gcc 2.7.2.3
  >  gtk+ 1.2    libgtk-1.2.so.0  gcc 2.7.2.3
  >  randomapp   N/A              gcc 2.7.2.3 (linked against glibc and gtk+)
  > 
  > Now, as I understand it, the purpose of sonames is to manage binary
  > compatibility of shared objects. Any file providing a soname
  > (libgtk-1.2.so.0, for example) should be compatible with all other files
  > that ever provided that soname. If somebody breaks that invariant, then my
  > system supposedly dies in flames.
  > 
  > As far as I can tell, breaking sonames is (1) incorrect from a technical
  > perspective, (2) disasterous for users and (3) really unprofessional.
  > 
  > Now, let's pretend that my vendor issues some updated gtk+ packages. These
  > are a bug fix release--and don't change any APIs--so they still use the
  > soname 'libgtk-1.2.so.0'. However, my vendor has chosen to compile this
  > library with egcs:
  > 
  >  Object      Soname           Compiler
  >  ------      ------           --------
  >  glibc 2.0   libc.so.6        gcc 2.7.2.3
  >  gtk+ 1.2    libgtk-1.2.so.0  egcs-1.0.3
  >  randomapp   N/A              gcc 2.7.2.3 (linked against glibc and gtk+)
  > 
  > In theory, randomapp should still run. After all, ld.so can still find
  > libraries with the appropriate sonames. But when I try to run randomapp,
  > things get ugly:
  > 
  >   undefined symbol: __register_frame_info
Yup.  As Zack and others have mentioned, this is a well known problem.

Back in 1997 we tried _very_ hard to convince Richard Kenner and Richard
Stallman to keep the old "__register_frame_info" interface in libgcc.a for
gcc2 for precisely this problem.

Against our recommendations, the interface was removed from gcc2.8.

jeff