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: hjl at lucon dot org
- Subject: Re: GCC-3.0.1 can't compile Glibc-2.2.4
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Tue, 2 Oct 2001 18:18:03 +0200
- CC: jakub at redhat dot com, 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> <20011002083908.B31936@lucon.org>
Date: Tue, 2 Oct 2001 08:39:08 -0700
From: "H . J . Lu" <hjl@lucon.org>
> 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.
The new libgcc_s.so.1 is still binary compatible with a previous
libgcc_s.so.1. It can handle all old DWARF-2 opcodes. The point is
that object modules created by the new GCC will be binary incompatible
with a previous libgcc_s.so.1.
Something has to be done. I don't know what the gcc people have
in mind.
AFAIK the solution that the GCC people have in mind is telling people
to upgrade their libgcc_s.so.1. To solve these kind of problems is
one of the reasons why they introduced the shared libgcc in the first
place. But why don't you ask them?
IMHO, they should have a new symbol version for those affected
functions.
That doesn't help. As I explained above this is not a libgcc_s.so.1
ABI issue.
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.
Which changes? We only add an unwinder to libc.so for the sake of
__frame_state_for. New C++ code will use the unwinder from libgcc_s.so.1.
> 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.
I'm pretty sure there are pre-gcc3 C++ binaries that are not linked
with libstdc++.
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.
That's something for Ulrich to decide. I remember him saying that he
didn't want the glibc release schedule dictated by the GCC release
schedule, and that he preferred to use the unwinder in libgcc_s.so.1
if it's available.
Mark