GCC 3.0 and GLIBC don't work together

[H . J . Lu]

On Tue, Jun 12, 2001 at 06:01:20PM +0200, Jakub Jelinek wrote:
> On Tue, Jun 12, 2001 at 04:38:31PM +0200, Andreas Jaeger wrote:
> 
> Speaking of GLIBC and GCC 3.0, we should I think finally decide what to do,
> because even if GCC 3.0 compiler GLIBC passed all tests, it will still be
> binary incompatible (e.g. __frame_state_for symbol will be missing) and it
> would be bad if someone started shipping GCC 3.0 compiler GLIBC without
> these issues sorted out.
> 
> Richard has included _Unwind_Find_FDE API in libgcc_s, so __frame_state_for
> can be built on top of that. Doing so requires glibc to have a copy of gcc
> old-style dwarf2 unwinder updated so that it copes with newly generated
> unwind directives.
> 
> Then, I think we have the following options:
> 
> - glibc will be linked without special options and appart from
>   __frame_state_for no other unwinding symbols will be exported from glibc.
>   Like this, glibc will have DT_NEEDED libgcc_s.so.1 which will provide the
>   whole interface and just glibc's __frame_state_for will use
>   _Unwind_Find_FDE to locate FDEs.
>   The advantages of this are that libgcc_s can be simply upgraded,
>   __frame_state_for code will have to be checked only if glibc is recompiled
>   with newer gcc.
>   The disadvantages include bigger memory footprint of every application
>   and bigger startup times due to one more shared library included in each
>   program.

I have once concern. If glibc has libgcc_s.so.1 in DT_NEEDED, that
means the glibc binary will depend on something outside of glibc,
which can be changed without the knowledge of glibc.

> - like the above, but libgcc_s.so.1 is DT_FILTER of glibc (requires the
>   current GLIBC semantics of DT_FILTER, not the one Solaris uses) - libgcc_s
>   has to be found in this case
> - glibc will be linked with -static-libgcc and will export
>   the usual __register_frame_info@@GLIBC_2.0 etc., and
>   __register_frame_info_bases@@GCC_3.0
>   __deregister_frame_info_bases@@GCC_3.0
>   __register_frame_info_table_bases@@GCC_3.0
>   _Unwind_Find_FDE@@GCC_3.0
>   Like this, glibc does not have to be linked to libgcc_s at all, but
>   if any library is linked against libgcc_s, it will find its FDEs just fine
> - like the above, but libgcc_s.so.1 is DT_AUXILIARY (in the GLIBC semantics
>   of DT_AUXILIARY) of glibc.

If we have to choose between DT_FILTER and DT_AUXILIARY, I prefer
DT_AUXILIARY since libgcc_s.so.1 doesn't have to exist.

What I'd like to see as an option is

1. gcc 3.0 can be configured not to build its own libgcc_s, but use
the system one if it exists.
2. glibc builds/uses/installs libgcc_s out of libgcc.a in gcc 3.0.

In this way, libgcc_s becomes the part of glibc.


H.J.