Re: [PATCH] Updated glibc-gcc3.patch

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Nov 16, 2001 at 04:15:35PM -0800, Ulrich Drepper wrote:
> > But is the __*register_frame* and _Unwind_Find_FDE in glibc really just
> > compatibility stuff?
> 
> You misunderstand the patch.  The code is left out for new ports and
> if somebody when compiling glibc specifies the oldest supported ABI is
> 2.2.5.  This is a special build which somebody has to select
> deliberately and which means s/he is completely taking compatibility
> issues in her/his own hands.  Nothing to worry about.  Something like
> this is useful if you build binaries for a closed environment you have
> complete control over.  This includes the compiler to use.

Nope, I understand what's the patch doing.
But, suppose a new port is contributed which uses the generic
unwind-dw2-fde.c gcc code (all but ia-64 currently). If
__register_frame_info and similar registry is not present in glibc, this
means all shared libs have to be linked against -lgcc_s (but ld.so and
libc.so). So -static-libgcc cannot be used to build whole glibc, and every
single binary will need to suffer similarly (in fact, all binaries will have
to be linked directly against it too, since when libc.so doesn't have
DT_NEEDED libgcc_s.so, they wouldn't have any registry to register with
(which is needed in case they dlopen C++ or Java libs).
Similarly with oldest supoprted ABI 2.2.5. Unless the compiler does
something similar to IA-64, of course.

But what I'm worried more is the GCC_3.0 vs. GLIBC_2.2.5 thing which
basically render this glibc change useless.
If we said we don't want compatibility with gcc 3.0.x, then gcc 3.1.x could
move those symbols to GLIBC_2.2.5 version and have GCC_3.0 symbols as
non-default aliases. But I'm afraid gcc 3.0.x compatibility is needed.

	Jakub