Re: GCC 3.0 and GLIBC don't work together

[Jakub Jelinek <jakub at redhat dot com>]

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.
- 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.

	Jakub