Re: GCC-3.0.1 can't compile Glibc-2.2.4

["H . J . Lu" <hjl at lucon dot org>]

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.