From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: Eric Kidd <eric.kidd@pobox.com>
Cc: egcs@egcs.cygnus.com, otaylor@redhat.com
Subject: Re: __register_frame_info & shared library compatibility 
Date: Fri, 30 Apr 1999 23:15:00 -0000
Message-ID: <3064.923442835@upchuck>
References: <19990406170202.J29505@moebius.dartmouth.edu>
X-SW-Source: 1999-04n/msg00196.html
Message-ID: <19990430231500.-8i9GuIgAuhKcRXahh_jCymaU_VSugXRPjh4-x9Dk_M@z>

  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