This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: glibc update problems
- To: Christopher Seawood <cls@seawood.org>
- Subject: Re: glibc update problems
- From: Jeffrey A Law <law@cygnus.com>
- Date: Wed, 17 Jun 1998 21:27:07 -0600
- cc: Allin Cottrell <cottrell@ricardo.ecn.wfu.edu>, libc-alpha@cygnus.com
- Reply-To: law@cygnus.com
In message <Pine.LNX.3.96.980615131637.3423A-100000@panic.can.seawood.org>you write:
> I ran into this problem as well. It seems that egcs/gcc-2.8 have the
> additional functions (de)register_frame_info as part of libgcc.a. Any
> shared library compiled will have these symbols. Any shared lib
> compiled with gcc-2.7 (redhat's glibc rpms) will not have these symbols.
>
> There was one point that's still a bit cloudy to me. In which of the
> following situations will one need to worry about (de)register_frame_info
> and will the symbols be defined in the shared lib or the executable?
>
> egcs-compiled libc with egcs-compiled program?
The symbols will be in libc and you will only run into problems if
you later remove libc and replace it with one compiled by gcc-2.7.
> egcs-compiled libc with gcc-2.7-compiled program?
Same as previous example, except that you don't have the problems
if you remove libc and replace it with one compiled by gcc-2.7
(since the program itself shouldn't have any references to the
problem symbols).
> gcc-2.7-compiled libc with egcs-compiled program?
The symbols will be defined by the main program and you should
be able to change your libc at-will without causing problems.
Basically problems arise when replacing a shared library with
a version compiled by an older compiler.
jeff