Re: __register_frame_info & shared library compatibility

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

On Tue, Apr 06, 1999 at 05:15:31PM -0400, Zack Weinberg wrote:
> This is a well known problem to which there is, unfortunately, no
> clean solution.

I was afraid of this. :-( Unless the distribution vendors are very careful,
migrating from gcc to egcs will cause as many problems as the libc5 to
glibc2 upgrade. Ugh.
 
> 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.

OK, this is starting to make sense. If __register_frame_info gets linked
into glibc-2.1, then any library linked against glibc will pick up the new
runtime functions? This seems like a fairly safe workaround, assuming that
everything using shared libraries links dynamically against glibc.

Does glibc 2.1 provide the soname libc.so.6? Does your solution somehow
rely on this fact, or are you advising me to break my system into two
parts: glibc 2.0 with gcc, and glibc 2.1 with egcs?

How does this solution affect pre-existing applications that were compiled
with egcs and linked against a glibc 2.0 that was compiled with gcc?

> 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).

I still don't understand something. Why should linking
__register_frame_info into glibc 2.1 solve the problem, but linking it into
glibc 2.0 *cause* the problem?

Is there any hope that Red Hat and other distribution vendors will get this
right, or will I have to spend a week or two cleaning up the mess?

Cheers,
Eric