[Christoph, please keep the python-dev list in the loop here, at least until they get annoyed and decide we're off-topic. I think this is crucial to the way they package and deliver Python]
Christoph Ludwig <[EMAIL PROTECTED]> writes: > On Thu, Jul 07, 2005 at 06:27:46PM -0400, David Abrahams wrote: >> "Martin v. Löwis" <[EMAIL PROTECTED]> writes: >> >> > David Abrahams wrote: >> >> I'm wondering if there has been a well-known recent change either in >> >> Python >> >> or GCC that would account for these new reports. Any relevant >> >> information would be appreciated. > [...] >> > Python is linked with g++ if configure thinks this is necessary >> >> Right. The question is, when should configure "think it's necessary?" > > Just to add to the confusion... I encountered the case that configure decided > to use gcc for linking but it should have used g++. (It is Python > PR #1189330 <http://tinyurl.com/dlheb>. This was on a x86 Linux system with > g++ 3.4.2.) > > Background: The description of --with-cxx in the README of the > Python 2.4.1 source distribution made me think that I need to > configure my Python installation with > --with-configure=/opt/gcc/gcc-3.4.2/bin/g++ if I plan to use C++ > extensions built with this compiler. (That was possibly a > misunderstanding on my part, AFAICT, yes. > but Python should build with this option anyway.) > > configure set `LINKCC=$(PURIFY) $(CC)'. The result was that make failed when > linking the python executable due to an unresolved reference to > __gxx_personality_v0. I had to replace CC by CXX in the definition of LINKCC > to finish the build of Python. > > When I looked into this problem I saw that configure in fact builds a test > executable that included an object file compiled with g++. If the link step > with gcc succeeds then LINKCC is set as above, otherwise CXX is > used. Obviously, on my system this test was successful so configure decided > to link with gcc. However, minimal changes to the source of the test program > caused the link step to fail. It was not obvious to me at all why the latter > source code should cause a dependency on the C++ runtime if the original > code does not. My conclusion was that this test is fragile and should be > skipped. Sounds like it. I have never understood what the test was really checking for since the moment it was first described to me, FWIW. > If Python is built with --with-cxx then it should be linked with CXX > as well. U betcha. > I gather from posts on the Boost mailing lists that you can import > Boost.Python extensions even if Python was configured > --without-cxx. Yes, all the tests are passing that way. > (On ELF based Linux/x86, at least.) That leaves me wondering > > * when is --with-cxx really necessary? I think it's plausible that if you set sys.dlopenflags to share symbols it *might* end up being necessary, but IIRC Ralf does use sys.dlopenflags with a standard build of Python (no --with-cxx)... right, Ralf? > * what happens if I import extensions built with different g++ versions? Will > there be a conflict between the different versions of libstdc++ those > extensions depend on? Not unless you set sys.dlopenflags to share symbols. It's conceivable that they might conflict through their shared use of libboost_python.so, but I think you have to accept that an extension module and the libboost_python.so it is linked with have to be built with compatible ABIs anyway. So in that case you may need to make sure each group of extensions built with a given ABI use their own libboost_python.so (or just link statically to libboost_python.a if you don't need cross-module conversions). HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ 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
