__register_frame_info & shared library compatibility

[Eric Kidd <eric dot kidd at pobox dot com>]

First, some background. I run Red Hat Linux 5.2, and build binaries for a
couple of projects involving shared libraries. I also maintain and upgrade
a number of Linux systems with locally compiled software.

egcs is starting to cause problems for me--or more precisely, the way
people *use* egcs is starting to cause problems for me. Let's start with
the latest problem I've encountered:

On Tue, Apr 06, 1999 at 11:23:23AM -0400, Owen Taylor wrote:
> Not true. As has been explained a couple of times here before, these
> RPM's are linked against glibc2.0. However, they are compiled against
> egcs. (The version of egcs shipped with 5.2, in fact)
>
> The consequence of the second thing is that you can't use those libraries
> with applications compiled with gcc, so if you want to compile other
> GNOME applications against these libraries, you'll temporarily have to
> make egcs your default compiler.

So here's the scenario, as best I understand it. My hypothetical system
initially contains:

 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

A little bit of research discovers something nasty: egcs and gcc have
incompatible runtimes, and ld.so can't deal with this gracefully. When you
compile a program with egcs, it pulls in a runtime providing
__register_frame_info. When you compile an application with gcc 2.7, it
pulls in an older runtime that lacks this symbol.

This apparently means that you can't use an egcs-compiled shared library
with a gcc-compiled application. Or am I missing something?

If my understanding is correct, however, my hypothetical system is now
broken. The bugfix upgrade to gtk+ broke binary compatibility for the
soname 'libgtk+-1.2.so.0', with potentially disasterous consequences.

Three questions for the audience:

 1) Am I badly confused? (I often am.)
 2) What happens if I recompile glibc 2.0 with ecgs and install it under
    the soname 'libc.so.6'?
 3) Will any of this cause bad problems in the future, and if so, how
    can these problems be prevented?

Thank you for your time!

Cheers,
Eric