This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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.1 can't compile Glibc-2.2.4


On Mon, Oct 01, 2001 at 10:28:32AM -0700, H . J . Lu wrote:
> On Wed, Sep 26, 2001 at 01:27:45PM -0700, H . J . Lu wrote:
> > On Wed, Sep 26, 2001 at 05:56:50AM -0400, Jakub Jelinek wrote:
> > > 
> > > > As I said above, the dependency is not very strict.  It only kicks in
> > > > in some corner cases.
> > > 
> > > I'd stress this. glibc will depend on libgcc_s.so.1 only for legacy C++
> > > applications (and only once new DWARF-2 opcodes are added), so IMHO it is
> > > not a big deal to do the dlopen.
> > 
> > Why is this dependency absolutely necessary? I'd prefer to have the
> > frame fuctions in glibc compatible with the gcc used to build glibc.
> > 
> 
> One more thing, when new DWARF-2 opcodes are added to libgcc, does
> anyone know what will happen to the interface of libgcc? Certainly,

I guess you're speaking about __frame_state_for, right? That's the only
thing glibc would like to dlopen libgcc_s for.
If new DWARF-2 opcodes are added to libgcc which cannot be handled by the
__frame_state_for interface, then bad luck, either abort() or terminate().
There isn't anything else what can be done actually, changing the
__frame_state_for interface would mean the binary compatibility would go
away anyway. glibc just passes execution to __frame_state_for in libgcc_s
(provided it finds it), giving it the same arguments.

If you speak about the registry functions, then Richard told us it is highly
unlikely this side will change soon, and if it changes to a binary
incompatible interface (with new symbol versions), glibc will have to
incorporate that. But that's true no matter whether glibc will dlopen
libgcc_s or not.

BTW: Concerning pre-gcc3 libstdc++, it might be easier solution to just
link the compatibility shared library against -lgcc_s. This way the unwind
stuff in glibc will be used only for C programs (the registry part, with
nobody using what was registered) or if a C program dlopens a C++ library
(that would be the only case where __frame_state_for from glibc is called).

	Jakub


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