This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


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

Re: GCC 3.0 Release Criteria


> From: Zack Weinberg <zack@wolery.cumb.org>
> Date: Thu, 27 Apr 2000 15:02:44 -0700
> Cc: rth@cygnus.com, mark@codesourcery.com, gcc@gcc.gnu.org,
>         libc-hacker@sourceware.cygnus.com
> Content-Disposition: inline
> User-Agent: Mutt/1.1.12i
> 
> On Thu, Apr 27, 2000 at 02:03:59PM -0700, Geoff Keating wrote:
> > > 
> > > Assume libfoo.so links against libgcc.a, includes a half-dozen functions
> > > (most notably __register_frame_info and company) and re-exports them.
> > 
> > Actually, this doesn't happen for __register_frame_info under linux:
> > 
> > 00000000  w   DF *UND*  000000e4  GLIBC_2.1.3 __cxa_finalize
> > 00000000  w   DF *UND*  000000f0  GLIBC_2.0   __deregister_frame_info
> > 00000000  w   DF *UND*  000000a8  GLIBC_2.0   __register_frame_info
> > 
> > I don't understand why, it's something to do with their being exported
> > from libc.so.
> 
> The frame functions are forcibly sucked into libc.so and reexported in
> order to prevent exactly the problem Richard describes. 

Well, yes, but since the link line is basically -lgcc -lc -lgcc I
don't understand why they don't end up in shared objects too because
the linker should find them in the first -lgcc.

> Or maybe I should say to prevent it from happening _again_, because
> it already happened in real life, around glibc-2.0.6.  Look at the
> libc-hacker archives for Nov 1998-Mar 1999, I think.

I remember that (turns pale, looks around for stiff drink).

-- 
- Geoffrey Keating <geoffk@cygnus.com>

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