This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: GCC vs GLIBC: why this stance, Drepper ?!?
- To: libc-alpha at sources dot redhat dot com
- Subject: Re: GCC vs GLIBC: why this stance, Drepper ?!?
- From: Paolo Carlini <pcarlini at unitus dot it>
- Date: Mon, 02 Jul 2001 13:10:52 +0200
- References: <20010630162231.A18131@lucon.org> <Pine.LNX.4.30.0106301526270.318-100000@straylight.int.sonicity.com> <20010701120217.F737@sunsite.ms.mff.cuni.cz>
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.