Re: [Python-Dev] GCC version compatibility
Christoph Ludwig [EMAIL PROTECTED] writes: --with-cxx=compiler: If you plan to use C++ extension modules, then on some platform you need to compile python's main() function with the C++ compiler. With this option, make will use compiler to compile main() *and* to link the python executable. It is likely that the resulting executable depends on the C++ runtime library of compiler. Note there are platforms that do not require you to build Python with a C++ compiler in order to use C++ extension modules. E.g., x86 Linux with ELF shared binaries and GCC 3.x, 4.x is such a platform. We recommend that you configure Python --without-cxx on those platforms to avoid unnecessary dependencies. I don't think that's strong enough. What happens is that dynamically loaded Python extension modules built with other, ABI-compatible versions of G++ may *crash*. If you need to compile main() with compiler, but your platform does not require that you also link the python executable with compiler (e.g., example platform), then set LINKCC='$(PURIFY) $(CC)' prior to calling make. Then the python executable will not depend on the C++ runtime library of compiler. Are we sure we have an actual use case for the above? Doesn't --without-cxx cover all the actual cases we know about? BTW, I'd also change the short explanation output by `configure --help'. Something like: AC_HELP_STRING(--with-cxx=compiler, use compiler to compile and link main()) In Python 2.4.1, the help message says enable C++ support. That made me use this option even though it turned out it is not necessary on my platform. Your suggestion is simple and powerful; I like it! -- 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
Re: [Python-Dev] GCC version compatibility
Christoph Ludwig [EMAIL PROTECTED] writes: I do not claim the 2 TUs test will cover all possible scenarios. I am not even sure this decision should be left to an automated test. Because if the test breaks for some reason then the user is left with a linker error that is time-consuming to track down. However, at least by the usual hierarchy of values, the sort of runtime error that results from the current needless linking with C++ on ELF/Linux is even worse. -- 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
Re: [Python-Dev] GCC version compatibility
[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
Re: [Python-Dev] GCC version compatibility
David Abrahams wrote: 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. I'll describe it once more: *If* a program is compiled with the C++ compiler, is it *then* possible to still link it with the C compiler? This is the question this test tries to answer. If Python is built with --with-cxx then it should be linked with CXX as well. U betcha. Wrong. The test was introduced in response to complaints that Python unnecessarily links with libstdc++ on some Linux systems. On these Linux systems, it was well possible to build main() with a C++ compiler, and still link the entire thing with gcc. Since main() doesn't use any libstdc++ functionality, and since collect2/__main isn't used, one would indeed expect that linking with CXX is not necessary. (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 This has no relationship at all. --with-cxx is much older than sys.dlopenflags. It is used on systems where main() must be a C++ program for C++ extension modules to work (e.g. some Linux systems). 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
Re: [Python-Dev] GCC version compatibility
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. So what about the theory that it may be that different versions of libstdc++ get linked? Python is linked with g++ if configure thinks this is necessary, and the g++ used to link the extension might be different. I'd like to see a backtrace of one such mysterious crash. 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
Re: [Python-Dev] GCC version compatibility
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. So what about the theory that it may be that different versions of libstdc++ get linked? That's been confirmed. Python is linked with g++ if configure thinks this is necessary Right. The question is, when should configure think it's necessary? and the g++ used to link the extension might be different. I'd like to see a backtrace of one such mysterious crash. I don't have it, but ldd confirms that the crash happens when the versions of libstdc++ in python and in the extension module are different. A C++ exception thrown from the extension module into the Boost.Python library to which it is linked (both compiled and linked with the same g++) without passing through any of Python's code (of course) will cause a crash unless Python is using the same libstdc++ as everything else, or unless Python isn't linked with libstdc++. -- 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
[Python-Dev] GCC version compatibility
Recently people testing Boost.Python with GCC on Linux have reported that the extensions being tested have to be compiled with exactly the same version of GCC as the Python they're being loaded into, or they get mysterious crashes. That doesn't correspond to my past experience; it has always been true that, as long as the compiler used to build Python and the one used to build the extension have compatible 'C' ABIs, we've been okay. Yes, if you were going to pass types like FILE* across the Python/C API, then you additionally need to be sure that the two compilers are using the same 'C' library. That said, none of the Boost.Python tests do that. 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. -- 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
