GCC-3.0.1 can't compile Glibc-2.2.4

[H . J . Lu]

On Tue, Oct 02, 2001 at 12:02:22PM +0200, Mark Kettenis wrote:
> 
>    If gcc does do #1, which I think is the right thing to do, does anyone
>    know how it will impact dlopening libgcc_s.so.1? To me, there are so
>    few benefits and so many unanswered questions, I don't think we should
>    do dlopening libgcc_s.so.1 at all.
> 
> I don't see how we can reliably implement #1.  If we don't dlopen
> libgcc_s.so.1 we might consider the unwinder and frame registration
> functions coupled for legacy C++ code, and do the checking you
> suggest, but libgcc_s.so.1 still enters the picture for new C++ code.
> Adding the checks that you suggest will not only make it impossible to
> compile glibc with future versions of GCC, but also make it impossible
> to simply use glibc with future versions of GCC.

I don't know what you were referring to.

> 
>    BTW, one way to implement #1 for gcc is to update the version of those
>    affected functions from GCC_3.0 to GCC_3.1, when the incompatible
>    changes are made, and make the GCC_3.0 version of those functions
>    invisible to ld. If gcc does that, we can check it in the glibc
>    configure to verify if gcc is compatible with glibc. I can write a
>    patch for that.
> 
> And what are in your view those affected functions?

You have to ask the gcc developers. All affected functions should have
a different version so that ld.so will refuse to load any binary which
references the new version. I don't know why you think it is impossible
to implement.

> 
> I repeat once more that coupling glibc to a particular version of GCC
> is something we should try to avoid.

Exactly, with some differences:

1. I don't want to couple glibc with a particular version of GCC, AT
THE RUN-TIME.
2. We should make the glibc in CVS compatible with the current gcc,
including those still under developement, if all possible.


H.J.