Re: __register_frame_info & shared library compatibility

[Zack Weinberg <zack@rabi.columbia.edu>]

On Tue, 6 Apr 1999 17:02:02 -0400, Eric Kidd wrote:
>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:
[...]
>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 is a well known problem to which there is, unfortunately, no
clean solution.

The best suggestion I can make is:  Get glibc 2.1 and compile it with
egcs.  When you do that, glibc absorbs and re-exports the runtime
functions that are causing the problem.  Everything else will pick
them up from there instead of libgcc.a.  You'll have to recompile any
libraries which are currently exporting __register_frame_info.  You
will not be able to run binaries built in this environment on
non-glibc-2.1 systems.

You can not do this with glibc 2.0 because then you lose binary
compatibility with glibc 2.0 compiled by gcc 2.7 (exact same problem
as you describe).

If your program and libraries are purely C, you can compile
*everything* with -fno-exceptions, which prevents the offending
functions from being linked in the first place.  You must not do this
if you care about C++.  Even if a library is written in C, it has to
use these functions to be compatible with C++ programs.  [I personally
think it's a mistake to use C++ for anything, but YMMV.]

zw