This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: __register_frame_info & shared library compatibility


On Tue, 6 Apr 1999 17:54:09 -0400, Eric Kidd wrote:
>On Tue, Apr 06, 1999 at 05:15:31PM -0400, Zack Weinberg wrote:
>> 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.

Yes.  To make sure it works, when you link shared libraries, put an
explicit -lc on the command line.  It is wise to use the same compiler
for all the libraries, but it should work to use gcc 2.7 to compile
executables.  (Modulo all the bugs in gcc 2.7...)

Make sure you have a current binutils (2.9.1.0.2x).  You may want to
upgrade to kernel 2.2; glibc 2.1 wants to use the new features (it
does fall back gracefully) and you won't have to keep gcc 2.7 around.

>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?

glibc 2.1 has the same soname as 2.0.  It is backward compatible as
long as your program does not use internal functions such as __write.
For some reason the most common mistake people make in this area is
to go groveling through the internals of the dynamic linker.  If you
get errors about symbols named _dl_somethingorother, that's the
problem.

Any library that uses stdio internally may need to be recompiled in
order to work with binaries built with glibc 2.1.  libstdc++,
libncurses, libslang, and libglib are known to need this.

Some C++ programs built with 2.0 break mysteriously when run on a 2.1
system.  This is due to bugs in the stdio backward compatibility
code.  We think we've fixed them all in 2.1.1, but there *is* always
one more bug :)

You can't use binaries or libraries compiled against 2.1 on a system
that has libc 2.0.  Hopefully everyone will be using 2.1 soon and this
won't be a problem.

>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?

Programs should work.  Libraries might not.

>> 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?

glibc 2.1 can't be compiled with gcc 2.7 (it miscompiles the math
library), so we make you use egcs, so __register_frame_info will
always be present in libc.so.6.  2.0 could be compiled with gcc 2.7,
and most distributions shipped it that way.

>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?

I know Debian's got it right, I think Redhat does too.  SuSE is having
problems, but will hopefully straighten out.  I don't know about the
others.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]