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

Christoph Ludwig cludwig at cdc.informatik.tu-darmstadt.de
Sat Jul 9 12:20:11 CEST 2005

On Sat, Jul 09, 2005 at 12:08:08AM +0200, "Martin v. Löwis" wrote:

David Abrahams wrote: >>When I looked into this problem I saw that configure in fact builds a test >>executable that included an object file compiled with g++. If the link step >>with gcc succeeds then LINKCC is set as above, otherwise CXX is >>used. Obviously, on my system this test was successful so configure decided >>to link with gcc. However, minimal changes to the source of the test program >>caused the link step to fail. It was not obvious to me at all why the latter >>source code should cause a dependency on the C++ runtime if the original >>code does not. My conclusion was that this test is fragile and should be >>skipped. > > > Sounds like it. I have never understood what the test was really > checking for since the moment it was first described to me, FWIW.

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" - my bug report #1189330 exihibts that the test fails to do its job. And looking at the test that's certainly no surprise:

configure writes the following conftest.cc on the disk (whitespaces added for better readability):

cludwig at lap200:~/tmp/python-config> cat conftest.cc void foo();

int main() { foo(); }

void foo() { }

This TU is compiled with the C++ compiler and then linked with the C compiler:

cludwig at lap200:/tmp/python-config> g++ -o conftest.o -c conftest.cc cludwig at lap200:/tmp/python-config> gcc -o conftest conftest.o

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

However, python.c does reference a function from other TUs, in particular extern "C" int Py_Main(int, char**). The following test shows that in this situation you must link with g++:

cludwig at lap200:~/tmp/python-config> cat conftest_a.cc extern "C" void foo();

int main() { foo(); } cludwig at lap200:/tmp/python-config> cat conftest_b.c void foo() { } cludwig at lap200:/tmp/python-config> g++ -o conftest_a.o -c conftest_a.cc cludwig at lap200:/tmp/python-config> gcc -o conftest_b.o -c conftest_b.c cludwig at lap200:/tmp/python-config> gcc -o conftest conftest_a.o conftest_b.o conftest_a.o(.eh_frame+0x11): undefined reference to `__gxx_personality_v0' collect2: ld gab 1 als Ende-Status zurück

(I ran this test with g++ 3.3.1, 3.4.2, and 4.0.0 with identical results.) The reason is, I guess, that even though foo() is delared to have "C" linkage, it still can throw a C++ exception.

>>If Python is built with --with-cxx then it should be linked with CXX >>as well. > > > U betcha.

Wrong. The test was introduced in response to complaints that Python unnecessarily links with libstdc++ on some Linux systems. On these Linux systems, it was well possible to build main() with a C++ compiler, and still link the entire thing with gcc. Since main() doesn't use _any libstdc++ functionality, and since collect2/main isn't used, one would indeed expect that linking with CXX is not necessary.

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.

>>(On ELF based Linux/x86, at least.) That leaves me wondering >> >> * when is --with-cxx really necessary? > > > I think it's plausible that if you set sys.dlopenflags

This has no relationship at all. --with-cxx is much older than sys.dlopenflags. It is used on systems where main() must be a C++ program for C++ extension modules to work (e.g. some Linux systems).

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

Regards

Christoph

http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

More information about the Python-Dev mailing list