Patches item #1324762, was opened at 2005-10-12 13:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Christoph Ludwig (cludwig) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling and linking main() with C++ compiler Initial Comment: The attached patch proposes a resolution to the discussion started in <url:http://thread.gmane.org/gmane.comp.python.devel/69651> regarding the compiler (C vs. C++) used to compile python's main() and to link the executable. The patch contains the following changes: 1) The configure option --with-cxx is renamed --with-cxx-main. This was done to avoid surprising the user by the changed meaning. Furthermore, it is now possible that CXX has a different value than provided by --with-cxx-main, so the old name would have been confusing. 2) The compiler used to translate python's main() function is stored in the configure / Makefile variable MAINCC. By default, MAINCC=$(CC). If --with-cxx-main is given (without an appended compiler name), then MAINCC=$(CXX). If --with-cxx-main=<compiler> is on the configure command line, then MAINCC=<compiler>. Additionally, configure sets CXX=<compiler> unless CXX was already set on the configure command line. 3) The command used to link the python executable is (as before) stored in LINKCC. By default, LINKCC='$(PURIFY) $(MAINCC)', i.e. the linker front-end is the compiler used to translate main(). If necessary, LINKCC can be set on the configure command line in which case it won't be altered. 4) If CXX is not set by the user (on the command line or via --with-cxx-main), then configure tries several likely C++ compiler names. CXX is assigned the first name that refers to a callable program in the system. (CXX is set even if python is built with a C compiler only, so distutils can build C++ extensions.) 5) Modules/ccpython.cc is no longer used and can be removed. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2006-04-14 16:36 Message: Logged In: YES user_id=21627 Thanks for the patch, committed as 45387. I modified it slightly, dropping the PROG_CXX_WORKS part, as selection of the C++ compiler is now entirely in the hands of the user. ---------------------------------------------------------------------- Comment By: Holger (jholg) Date: 2006-04-10 16:32 Message: Logged In: YES user_id=1315684 Forgot to mention the python version: I used it for both 2.4.2 and 2.4.3. >I can confirm cxx-main.patch3 fixes build problems with gcc >3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++. ---------------------------------------------------------------------- Comment By: Holger (jholg) Date: 2006-04-10 16:28 Message: Logged In: YES user_id=1315684 I can confirm cxx-main.patch3 fixes build problems with gcc 3.4.4 on Solaris 8, enabling me to _not_ link to libstdc++. I also think the patched README text is clearer than the original. Just my +1 for this patch. ---------------------------------------------------------------------- Comment By: Christoph Ludwig (cludwig) Date: 2005-11-30 19:07 Message: Logged In: YES user_id=1266029 My second patch was indeed broken since it referred to $CC before the call to AC_PROG_CC in configure.in. That caused CC=gcc and CXX=c++ if neither --with-cxx-main nor CC was given on the command line. I am going to upload a third version (cxx-main.patch3) that fixes this problem by moving the code that evaluates --with-cxx-main below AC_PROG_CC. To repeat what I wrote in my last comment: This patch does not address the issue that distutils calls $CC in order to compile C++ source files and calls $CXX in the linking step only. Howevr, the patch tries to ensure that CXX is always set to a sensible value in the Makefile - even if Python is built exclusively with $CC. Thus, distutils has a fighting chance to do the right thing (whatever that is) when building C++ extensions since it uses the value of CXX found in Python's Makefile. ---------------------------------------------------------------------- Comment By: Christoph Ludwig (cludwig) Date: 2005-11-25 11:51 Message: Logged In: YES user_id=1266029 distutils behaves the same way in Python 2.4.1, as I mentioned <url:http://article.gmane.org/gmane.comp.python.devel/69817>. My patch does not address this problem at all. (It should be fixed in distutils, but I did not the time to look into it yet.) I am surprised that, on your machine, CC=gcc and CXX=c++. I will look into this next week. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-11-25 00:26 Message: Logged In: YES user_id=45365 Well, as I commented on this patch and you quickly followed my suggestions I felt obliged to test your fix, but I'm not sure about the outcome. I built a C++ extension on MacOSX 10.4, gcc 4, framework Python. The good news is that it worked fine, everything built and worked as before. BUT: both with and without your mods my C++ modules are compiled with "gcc", not "g ++" or "c++". Linking is done with "c++", in both cases. I looked at distutils and it seems that it could indeed be the case that CXX is only used for linking and never for compilation, but I'm not 100% sure. Additionally, the Makefile has CC= gcc CXX= c++ which is technically fine on my machine (g++ == c++), but may not work always. Maybe someone who has a machine with both cc/c++ and gcc/g++ installed, and preferrably incompatible compilers, could give this patch a try too? ---------------------------------------------------------------------- Comment By: Christoph Ludwig (cludwig) Date: 2005-11-10 19:42 Message: Logged In: YES user_id=1266029 I am going to upload a revision of my patch that addresses jackjansen's comment: It sets CXX to g++ or c++ if CC is gcc or cc, respectively. Additionally, it writes a warning if configure had to "guess" the C++ compiler and tells the user how to override this guess. The change is in lin with jackjansen's second suggestion. It is pretty straight forward and avoids fragile configure magic. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2005-11-08 23:51 Message: Logged In: YES user_id=45365 One question: is step 4 a wise idea? Picking a random C++ compiler if multiple are available may result in picking a vendor C++ when the user has specified CC=gcc, for example. OTOH, actually doing the configure magic to determine that the selected C++ works together with the c-compiler selected for Python may be overkill too. Maybe try only standard combinations cc/c++ gcc/g++ and otherwise require --with{out}-cxx? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1324762&group_id=5470 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
