Re: GCC vs GLIBC: why this stance, Drepper ?!?

[Paolo Carlini <pcarlini at unitus dot it>]

Hi,

Jakub Jelinek wrote:

> > Would gcc 3.0 with static libgcc_s work for recompiling glibc?
>
> You can surely recompile it, but it won't be binary compatible.
> __frame_state_for will be missing, plus glibc won't export the needed new
> __register_frame_info_bases etc. symbols, so if you mixed such glibc and
> some G++ 3.0 compiled library, you'd use two different registration points
> for shared libraries, one in glibc, one in probably libstdc++. So things
> would or would not work properly depending on the particular library order
> (e.g. try dlopening a library written in C++ from a C only main program and
> throw exceptions through sort).
>
> GLIBC definitely needs a __frame_state_for implementation, plus its
> interaction with libgcc_s.so needs to be decided (see
> http://sources.redhat.com/ml/libc-hacker/2001-06/msg00020.html).

With difficulties I'm trying to follow the issues discusses in these threads...

I would try to summarize something:
1- There is a ("political", I would say) configuration/install issue which may
involve (not necessarily, however) GCC (that discussed mostly by H.J. Lu).
2- There is a mostly unrelated ("technical", I would call it) compile-time issue
which involves mostly GLIBC (that discussed above by Jakub Jelinek).

Now I'm wondering if those two could be dealt with separately.

To be clear, I mean Jakub Jelinek proposing a patch vs 2.2.3 which would lead to
a perfectly functioning, up to date glibc2.2.x + gcc3.0 based system for the
great satisfaction of those people (like me! ;-) who have no difficulties at
all with a "system" libgcc_s.so.

Thanks,
Paolo Carlini.