This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: __register_frame_info & shared library compatibility
- To: law at cygnus dot com
- Subject: Re: __register_frame_info & shared library compatibility
- From: Zack Weinberg <zack at rabi dot columbia dot edu>
- Date: Tue, 06 Apr 1999 20:35:42 -0400
- cc: Eric Kidd <eric dot kidd at pobox dot com>, otaylor at redhat dot com, egcs at egcs dot cygnus dot com
On Tue, 06 Apr 1999 17:46:23 -0600, Jeffrey A Law wrote:
>
> In message <199904062115.RAA15222@blastula.phys.columbia.edu>you write:
> > 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).
>This points out the terrible problem with the patch to make the *_frame_info
>functions weakly referenced in crtstuff.
>
>We're already getting reports of programs that no longer run because of this
>change. We may have to revert it.
That's strange. That patch should theoretically make shared libs
compiled by egcs act like shared libs compiled by gcc.
The correct binary interface for libc 2.0 is the one you get if you
compile all purely C libraries with gcc 2.7. Programs that expect
something else are broken, sorry. (There's no reason to prefer this
rule except that that's what all the major distributions shipped.)
zw