GCC-3.0.1 can't compile Glibc-2.2.4

[Mark Kettenis]

   Date: Tue, 2 Oct 2001 08:39:08 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   > If new DWARF-2 opcodes are added to libgcc which cannot be handled by the
   > __frame_state_for interface, then bad luck, either abort() or terminate().
   > There isn't anything else what can be done actually, changing the
   > __frame_state_for interface would mean the binary compatibility would go
   > away anyway. glibc just passes execution to __frame_state_for in libgcc_s
   > (provided it finds it), giving it the same arguments.
   > 
   > If you speak about the registry functions, then Richard told us it is highly
   > unlikely this side will change soon, and if it changes to a binary
   > incompatible interface (with new symbol versions), glibc will have to
   > incorporate that. But that's true no matter whether glibc will dlopen
   > libgcc_s or not.

   You mised the point. When the new DWARF-2 opcodes are added to libgcc,
   the new libgcc_s.so.1 is no longer binary compatible with the previous
   ones.

The new libgcc_s.so.1 is still binary compatible with a previous
libgcc_s.so.1.  It can handle all old DWARF-2 opcodes.  The point is
that object modules created by the new GCC will be binary incompatible
with a previous libgcc_s.so.1.

   Something has to be done. I don't know what the gcc people have
   in mind.

AFAIK the solution that the GCC people have in mind is telling people
to upgrade their libgcc_s.so.1.  To solve these kind of problems is
one of the reasons why they introduced the shared libgcc in the first
place.  But why don't you ask them?

   IMHO, they should have a new symbol version for those affected
   functions.

That doesn't help.  As I explained above this is not a libgcc_s.so.1
ABI issue.

   No, I am not talking about __frame_state_for.  I really don't see
   why we should dlopen libgcc_s.so.1 if we incorporate those changes
   into glibc.

Which changes?  We only add an unwinder to libc.so for the sake of
__frame_state_for.  New C++ code will use the unwinder from libgcc_s.so.1.

   > BTW: Concerning pre-gcc3 libstdc++, it might be easier solution to just
   > link the compatibility shared library against -lgcc_s. This way the unwind
   > stuff in glibc will be used only for C programs (the registry part, with
   > nobody using what was registered) or if a C program dlopens a C++ library
   > (that would be the only case where __frame_state_for from glibc is called).
   I am not sure if all pre-gcc3 C++ binaries are linked with libstdc++
   dynamically.

I'm pretty sure there are pre-gcc3 C++ binaries that are not linked
with libstdc++.

   If we can keep glibc current with gcc, which I think we
   should do anyway, I don't believe we should dlopen libgcc_s.so.1.

That's something for Ulrich to decide.  I remember him saying that he
didn't want the glibc release schedule dictated by the GCC release
schedule, and that he preferred to use the unwinder in libgcc_s.so.1
if it's available.

Mark