From mboxrd@z Thu Jan  1 00:00:00 1970
From: Zack Weinberg <zack@rabi.columbia.edu>
To: law@cygnus.com
Cc: egcs@egcs.cygnus.com
Subject: Re: __register_frame_info & shared library compatibility 
Date: Fri, 30 Apr 1999 23:15:00 -0000
Message-ID: <199904101341.JAA27027@blastula.phys.columbia.edu>
References: <852.923732922@upchuck>
X-SW-Source: 1999-04n/msg00366.html
Message-ID: <19990430231500.Hzkv34ucdiwTUo92_AUX7TAlLVPent6COtmgR4yIDZE@z>

On Sat, 10 Apr 1999 02:28:42 -0600, Jeffrey A Law wrote:
>
>  > * GNU libc compiled with gcc 2.8, egcs-1.1 should not contain or
>  >   reference __register_frame_info [1].
>Incorrect.  If you compile glibc with egcs-1.1, then the resulting library
>will have __register_frame_info.  This happens because the C startup files
>have a reference to __register_frame_info, which in turn cause
>__register_frame_info to be brought in from libgcc::frame.o.
>
>Furthermore, the definition in the library will have external visibility.

This is true or not true depending on which point revision of glibc
2.0 you have.  Patches were added somewhere in there which prevent
libc.so from exporting __register_frame_info - it uses its own private
crtbeginS.o (effectively) which has the weak symbol refs.

Unfortunately, that just means the externally visible definition of
__register_frame_info moves over to libm.so.

To make matters worse, I think this particular patch was added to libc
CVS after Ulrich stopped making official point releases.  That means
Redhat and Debian have it and no one else does.

>  > * All programs compiled with gcc 2.8 or egcs-1.1 and linked
>  >   only against libc contain and reference __register_frame_info.
>Depends on whether or not they link against any libraries which provide
>register_frame_info.

He said `only against libc'.  We always do -lgcc -lc -lgcc, so the
above assertion is correct.

>  > * All programs compiled with gcc 2.8 or egcs-1.1 and linked against an
>  >   other shared library besides libc do not contain
>  >   __register_frame_info but do reference __register_frame_info.
>Incorrect.  It depends on what is in the libraries that the program is
>linked again.

In practice, this assertion is correct if and only if the `other
shared library' was compiled with egcs with a version number in
[1.0, 1.1.1] or with gcc 2.8.

>  > Now there are a few possibilities where programs will not run:
>I've already explained the cases where program will stop running.
>
>If you have a program which is linked against a shared library and the
>shared library originally contained the frame functions, then that program
>will expect to get the frame functions from the library and will not have
>its own copies.
Yes.

>If you then recompile that library with egcs-1.1.2, then that library may
>not get a copy of the frame functions if the only reference to them is
>the weak symbol in the crt*.o files.
Yes.

>Now the progrm which was originally linked against that library will fail
>because there is no definition of the frame functions.
Yes.

>This problem can be solved by making the reference to the frame function
>in the crt files a normal (non-weak) reference again.  This will not break
>existing code.

This is technically true, however you will break people's
expectations.  Libc has been going around telling everyone that they
need to compile their libraries with gcc 2.7 or else apply the
controversial patch to egcs.  Oh, and the patch is official in egcs
1.1.2.  From libc's point of view, any library that was not compiled
as above is broken; it fails to conform to the de facto ABI.

zw