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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4