[C++-sig] [Python-Dev] GCC version compatibility

["Martin v. Löwis"]

Christoph Ludwig wrote:
>>I'll describe it once more: *If* a program is compiled with the C++
>>compiler, is it *then* possible to still link it with the C compiler?
>>This is the question this test tries to answer.
> 
> 
> The keyword here is "tries"

Any such test would only "try": to really determine whether this is
necessary for all possible programs, one would have to test all possible
programs. Since there is an infinite number of programs, this test could
take a while.

The original test, on the original system, would cause __main to be
undefined, and then decide to use C++. For a long time, on systems
that don't use collect2, the test *correctly* determined that linking
with g++ was not necessary.

It is only recent changes to g++ that break the test, namely the
introduction of this __gxx_personality_v0 thing.


> - my bug report #1189330 exihibts that the test
> fails to do its job. And looking at the test that's certainly no surprise:

However, it *is* a surprise that your modified test fixes the problem.

> Note that there is *no* reference to any symbol in another TU. The compiler
> can detect that foo() won't throw any exceptions, that there is no need for RTTI
> and whatever else the C++ runtime provides. Consequently, the object file
> produced by g++ does not contain any reference to symbols in libstdc++.

You are assuming implementation details here. I have seen
implementations of C++ (eg. g++ with collect2) where the test determines
that linking with C++ is necessary (because __main was undefined), as
well as systems where the test decides *correctly* that linking with
C++ is not necessary (e.g. gcc 2.x on an ELF system). That some C++
compiler introduces the C++ runtime if some C function may throw an
exception is a very specific detail of this C++ compiler.

> Of course, if you insist on this "dependency optimization" then you can try to
> fix Python's configure.in by using the second test above. But I would still
> not trust it to cover all configurations on all platforms supported by
> Python. 

Of couse not. This is just autoconf: it does not allow magical porting
to all possible future operating systems. Instead, from time to time,
explicit porting activity is necessary. This is not just about this
specific detail, but about many other details. Each new operation
system, library, or compiler version might break the build process.

> Can you provide a concrete examples of such systems? The explanation of
> --with-cxx in the README mentions a.out. Are there other systems?

I'm not sure. I think HP-UX (with OMF, and aCC) might have required
the same code, as may have SysVR3 (with COFF).

Regards,
Martin