GCC-3.0.1 can't compile Glibc-2.2.4
H . J . Lu
hjl@lucon.org
Tue Oct 2 09:37:00 GMT 2001
On Tue, Oct 02, 2001 at 06:18:03PM +0200, Mark Kettenis wrote:
>
> 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
That is the only solution. I was referring how to detect the problem.
> one of the reasons why they introduced the shared libgcc in the first
> place. But why don't you ask them?
I have asked it before and even proposed a patch, which should work
for all platforms, not just glibc. But noone was interested. That is
why I only focus on glibc.
>
> 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.
It helps to detect the incompatibility at the load time, not when the
exception is thrown. I do believe it should be a requirement for
glibc.
>
> 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.
Those used to implement __frame_state_for.
>
> > 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.
It is never the case. I believe people who compile his/her glibc should
know what he/she is doing. They should keep track glibc in CVS.
H.J.
More information about the Libc-alpha
mailing list