On Sun, Jul 10, 2005 at 09:45:25AM +0200, "Martin v. Löwis" wrote:
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.
Sure. You cannot write a test that gives the correct result for all platforms you can think of, covering every compiler / linker quirk. I never claimed that is possible. My point is: The test implemented in the 2.4.1 configure script gives a wrong result if your platform happens to be x86 Linux with ELF binaries and g++ 4.0.
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.
The test broke due to a change in GCC 4.0, but the "__gxx_personality_v0 thing" was introduced long before. It is merely a symptom. I ran the tests with GCC 3.3.1, 3.4.2, and 4.0.0. Here are the results: GCC version 1 TU 2 TUs 3.3.1 g++ g++ 3.4.2 g++ g++ 4.0.0 gcc g++ (1 TU: test with one translation unit, as in Python 2.4.1. 2 TUs: test with two translation units, as in my last posting. g++ / gcc: test indicates linking the executable requires g++ / gcc, respectively.) With GCC 3.3.1 and 3.4.2, linking of the executable conftest in the 1 TU test fails because of an unresolved symbol __gxx_personality_v0. Therefore, python is linked with g++. The change that makes GCC 4.0.0 break the 1 TU test is that the compiler apparently does a better job eliminating unreachable code. In the 1 TU test, it recognizes __gxx_personality_v0 (or the code that refers to this symbol) is unreachable and removes it. It seems there are no other symbols left that depend on libstdc++ so suddenly conftest can be linked with gcc.
- 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.
I am not aware of any rule that makes the following program ill-formed: // in a.cc: extern "C" void foo(); int main() { foo(); } // in b.cc extern "C" void foo() { throw 1; } Provided the compiler does not do optimizations across translation units, it has no way to determine in a.cc whether foo() is really a C function (i.e., compiled by a C compiler) or a C++ function with "C" linkage. I think a conforming C++ compiler has to provide for the case that foo() might throw. It was a very specific detail of gcc 2.x if it failed to do so. (A venial omission, I admit.) But I digress. It's not that important for our discussion whether a C++ compiler must / should / is allowed to add exception handling code to the call of an extern "C" function. The point is that some do *unless* they see the function definition. I contend the test involving two TUs matches more closely the situation with ccpython.cc than the current test. I do not claim the 2 TUs test will cover all possible scenarios. I am not even sure this decision should be left to an automated test. Because if the test breaks for some reason then the user is left with a linker error that is time-consuming to track down.
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.
Instead of having yet another test in configure.in that may break on a new platform and that needs maintenance wouldn't it be better to assume that --with-cxx implies linking with the C++ compiler and telling users how to override this assumption? Would it cause so much inconvenience to users provided the explanation of --with-cxx in the README would be modified? I think of an explanation along the lines of: --with-cxx=<compiler>: If you plan to use C++ extension modules, then on some platform you need to compile python's main() function with the C++ compiler. With this option, make will use <compiler> to compile main() *and* to link the python executable. It is likely that the resulting executable depends on the C++ runtime library of <compiler>. Note there are platforms that do not require you to build Python with a C++ compiler in order to use C++ extension modules. E.g., x86 Linux with ELF shared binaries and GCC 3.x, 4.x is such a platform. We recommend that you configure Python --without-cxx on those platforms to avoid unnecessary dependencies. If you need to compile main() with <compiler>, but your platform does not require that you also link the python executable with <compiler> (e.g., <example platform>), then set LINKCC='$(PURIFY) $(CC)' prior to calling make. Then the python executable will not depend on the C++ runtime library of <compiler>. BTW, I'd also change the short explanation output by `configure --help'. Something like: AC_HELP_STRING(--with-cxx=<compiler>, use <compiler> to compile and link main()) In Python 2.4.1, the help message says "enable C++ support". That made me use this option even though it turned out it is not necessary on my platform. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html