David Abrahams 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.
Okay, I understand that. What I have never understood is why that should be an appropriate thing to test for the Python executable. There's no reason to compile any of Python with a C++ compiler.
I hope you understand now: it is necessary if you want to link C++ extension modules into a Python interpreter (statically, not dynamically).
Wrong. The test was introduced in response to complaints that Python unnecessarily links with libstdc++ on some Linux systems.
Apparently it still does.
Not "still", but "again", since recent changes in gcc.
On these Linux systems, it was well possible to build main() with a C++ compiler
Nobody would need to build Python's main() with a C++ compiler, if you'd just comment out the 'extern "C"'.
Wrong. People that statically link C++ extensions modules on systems where the C++ compiler requires main to be compiled as C++ need to do such a thing. One such compiler is gcc on systems where the binary format does not support .init sections.
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.
Hmmm. It is. Try for yourself. You get an unresolved gxx_personality_v0.
I have tested Boost.Python and C++ extension modules on a wide variety of Linux systems, and have seen this phenomenon.
Did you try on Linux systems released 1994? That don't use ELF as the binary format?
I think either the ELF Linux loader changed substantially since 1995, or whoever introduced this test was just confused.
No. The ELF loader was *introduced* since 1995. Dynamic loading was not available before.