Duncan Grisby writes:
2) No global objects as we are linking against a C compiled Python.
There is a patch posted on the C++ SIG website, which modifies the configure script for Python to allow you to get your main linked with C++, which ensoures that global ctors get run correctly. If you use that, you don't need rule 2) above.
I'm intrigued by the assertion that you can't use global objects when the Python executable is compiled with C. For which platforms is it true?
C does not have global ctors, so if you build a C program, you can't expect C++ global ctors to get run, unless you have detailed, platform-specific knowledge to the contrary. Exactly how global ctors get run in C++ is platform specific. The standard just mandates that global ctors get run before main() is called. Exactly how it happens depends on the compiler. I think Myers explains this in his first book at some length.
I've successfully used global C++ objects with constructors on Linux, Solaris and Windows NT, without compiling Python itself with C++.
You were lucky. That's the linker being nice to you.
I've done this while providing Python bindings for omniORB. My Python extension module does not have any global objects itself, but it is (dynamically) linked with the main omniORB library which does. Maybe that's why it works?
Many dynamic linkers do the global ctor thing correctly. BTW, this is not just ELF as was mentioned in a sperate post. In general, a good dynamic linker ought to understand the notion that a dynloaded library might need initialization or finalization code to be run. But that's part of the ABI for a computing platform, not the C++ language definition. On the other hand, if you build a Python with a C++ extension module statically linked in, it will quite likely fail, unless the C++ compiler compiles main(), and drives the link. In this case, the issue is not just getting the special initialization and finalization code to be draped around main(), but also because of the need to perform implicit instantiations. Again, one can luck out. Some systems have linkers that "do it right" irrespective of what the compilers did. And some compilers use gross bloating template instantiation techniques that ensure simplistic linkage models will "work", but do so at the expense of bloating executable size, and consequent reductions in I-cache locality. But if you want it to work because you did it right, and not merely because you were lucky, then you need to compile main() with C++, and let C++ run the link. -- Geoffrey Furnish Actel Corporation furnish@actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303 "... because only those who write the code truly control the project." -- Jamie Zawinski