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: Justin Guyett <jfg at sonicity dot com>
- Subject: Re: GCC vs GLIBC: why this stance, Drepper ?!?
- From: Jakub Jelinek <jakub at redhat dot com>
- Date: Sun, 1 Jul 2001 12:02:18 +0200
- Cc: gcc at gcc dot gnu dot org, libc-alpha at sources dot redhat dot com
- References: <20010630162231.A18131@lucon.org> <Pine.LNX.4.30.0106301526270.318-100000@straylight.int.sonicity.com>
- Reply-To: Jakub Jelinek <jakub at redhat dot com>
On Sat, Jun 30, 2001 at 03:41:28PM -0700, Justin Guyett wrote:
> rh gcc 2.96 snapshot. Does the 2.95.4 snapshot used by debian have those
> two patches in it?
I believe they have the atexit patch, it is in CVS after all.
Dunno about the __dso_handle exporting patch without which atexit won't work
properly.
> 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).
Jakub