[Python-Dev] Linux Python linking with G++?

David Abrahams dave at boost-consulting.com
Sat Jul 9 03:20:26 CEST 2005


"Martin v. Löwis" <martin at v.loewis.de> writes:

> David Abrahams wrote:
>> Unless, of course, I'm missing something.  So if I am missing
>> something, what is it?
>
> You are missing something, and I can only repeat myself. Some systems
> require main() to be compiled as C++, or else constructors may not work
> (and perhaps other things fail as well). 

Yes, and that becomes important in programs that have constructors.
I.e., C++ programs.  The Python executable is not such a program,
except for one C++ file: ccpython.cc.  There is no reason that file
couldn't be rewritten as a pure 'C' file and any need for Python to be
linked with G++ would disappear.

> The configure option --with-cxx (documented as "enable C++ support")
> make Python C++ options 

What are "Python C++ options?"

> work on such systems. It is automatically enabled if a C++ compiler
> is found.
>
> There is configure auto-detection for what linker is used when
> ccpython.o becomes main().
>
> This is the state of the things as it is. In what way would you like to
> see that state changed?

I would like the Python executable never to be linked (or compiled
either) by g++ unless that is explicitly requested by the person
invoking configure or make.

> I could personally accept if ccpython and --with-cxx would be dropped
> entirely (i.e. deliberately breaking systems which require it); 

I don't believe any systems require it.  I realize you have said
otherwise, but after years of working with Boost.Python I'm very
familiar with the issues of dynamic linking and C/C++ interoperability
on a wide variety of platforms, and I'm not convinced by your
assertion.  If such a system exists, it should be easy for someone to
point me at it, and show that something breaks.

> I just notice the irony of history: ccpython.cc was originally
> introduced to better support C++ extension modules - now it might
> get removed for the very same reason (to better support C++
> extension modules).

Indeed.  I was amazed to read in the log that it was introduced in
1995 for that reason.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com


More information about the Python-Dev mailing list