This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: GCC-3.0.1 can't compile Glibc-2.2.4
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: GCC-3.0.1 can't compile Glibc-2.2.4
- From: "H . J . Lu" <hjl at lucon dot org>
- Date: Tue, 2 Oct 2001 08:39:08 -0700
- Cc: Mark Kettenis <kettenis at wins dot uva dot nl>,libc-alpha at sources dot redhat dot com
- References: <20010924103415.B17065@lucon.org> <s3ik7yoz31v.fsf@soliton.wins.uva.nl> <20010925102111.B9236@lucon.org> <200109252357.f8PNvs306972@delius.kettenis.local> <20010925171933.A16536@lucon.org> <200109260924.f8Q9OFb07011@delius.kettenis.local> <20010926055650.A25384@devserv.devel.redhat.com> <20010926132745.B1529@lucon.org> <20011001102832.A12158@lucon.org> <20011002122016.I3251@sunsite.ms.mff.cuni.cz>
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.