Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Aug 05, 2002 at 10:03:51AM +0200, Martin v. Loewis wrote:
> Jakub Jelinek <jakub@redhat.com> writes:
> 
> > Here I don't understand what you mean. If one gcc was configured against
> > 2.12 binutils (2.12.1+ or plain 2.12 (which shouldn't be used)?), then
> > it forever requires those binutils, as it passes --eh-frame-hdr from
> > specs (and relies on PT_GNU_EH_FRAME being present, so
> > that __register_frame* calls are not necessary in the crtstuff).
> > Which crtstuff is used is picked at link time and at the same time
> > you either pass or don't pass --eh-frame-hdr, so you either rely on
> > PT_GNU_EH_FRAME or don't.
> 
> What happened was this: System A has ld 2.12.90.0.14 20020627 Debian
> GNU/Linux. A binary "test" is created with g++ 3.1.1 on this system
> (compiled and linked).
> 
> System B has ld 2.11.92.0.10 20011021 (SuSE). g++ 3.3 20020804 is
> built on this system, including libgcc_s.so.1.
> 
> The binary "test" is copied from A to B. When run on B, it crashes.
> 
> Notice that B's binutils are not used at all - this is purely an ABI
> issue. Yet still their version number alone resulted in a binary
> incompatibilitity - if I copy libgcc_s.so.1 from A to B also, "test"
> works fine.
> 
> I'll attach the source code test.cc below.

The compatibility is only backward compatibility, not forward compatibility.
So if you build binaries/libraries on a system with PT_GNU_EH_FRAME capable
g++/libgcc_s, you need to use that libgcc_s wherever you run those programs.

On the other side, programs/binaries built on g++/libgcc_s not
PT_GNU_EH_FRAME aware will run against PT_GNU_EH_FRAME aware libgcc_s.

That's why I propose that in order to build g++ 3.2 interoperable with
everyone else glibc 2.2.5+, binutils 2.12.1+ and --enable-shared
--enable-threads=posix --enable-__cxa_atexit is required.
We could even cook up a testsuite which wether g++/libgcc_s/libstdc++ follow
those requiremenets.

	Jakub