[Python-Dev] [C++-sig] GCC version compatibility (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Sun Jul 10 09:45:25 CEST 2005

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

More information about the Python-Dev mailing list