David Abrahams wrote: > 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.
That is not true. ccpython was introduced to support builds of the Python interpreter where some modules are C++. As you know, people do write extension modules in C++. > 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. There is already a version of that file in C, Modules/python.c. This is used when --with-cxx is not given. >>The configure option --with-cxx (documented as "enable C++ support") >>make Python C++ options work on such systems. > > > What are "Python C++ options?" Oops, meant "Python C++ extension modules" (it must have been late when I wrote that). >>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 well remember that gcc 2.5.8 on Linux a.out required this sort of setup. Dynamic linking was not supported at all on that system (atleast not in a way where users could easily write shared libraries themselves). Rebuilding the Python interpreter was the only option to integrate additional modules. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
