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 Tue, Oct 02, 2001 at 12:20:16PM +0200, Jakub Jelinek wrote:
> > 
> > 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.

No, all those functions affected by the new DWARF-2 opcodes.

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

You mised the point. When the new DWARF-2 opcodes are added to libgcc,
the new libgcc_s.so.1 is no longer binary compatible with the previous
ones. Something has to be done. I don't know what the gcc people have
in mind. IMHO, they should have a new symbol version for those affected
functions. No, I am not talking about __frame_state_for. I really don't
see why we should dlopen libgcc_s.so.1 if we incorporate those changes
into glibc.

> 
> 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).

I am not sure if all pre-gcc3 C++ binaries are linked with libstdc++
dynamically. If we can keep glibc current with gcc, which I think we
should do anyway, I don't believe we should dlopen libgcc_s.so.1.


H.J.


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