[Python-Dev] GCC version compatibility

["Martin v. Löwis"]

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.
> 
> 
> It isn't.

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.

Regards,
Martin