| msg48477 - (view) |
Author: Antti Honkela (ahonkela) |
Date: 2005-06-17 12:29 |
| Add more proper C++ compilation support to distutils by propagating information on used language to compiler as well as linker. The information is used by unixccompiler, cygwinccompiler and emxccompiler to call a C++ compiler instead of a C compiler. Options for the call are formed by as a union of options to both C and C++ compilers. The old version worked by accident on some platforms where you can compile C++ programs by calling the C compiler (e.g. gcc), but not on others (e.g. Tru64 Unix, probably also others not using gcc). The more compilcated handling of options than with linker is necessary to properly support manual overrides such as "CXX=g++ -foo". The attached patch is against CVS HEAD, but applies with minimal changes at least to Python 2.3. |
|
|
| msg59307 - (view) |
Author: Christian Heimes (christian.heimes) *  |
Date: 2008-01-05 19:22 |
| Isn't it already fixed? Need to check it at the upcoming bug day. |
|
|
| msg93211 - (view) |
Author: David Kirkby (drkirkby) |
Date: 2009-09-28 14:33 |
| Just to add, I'd much appreciate if this bug could be squashed. I see there is a patch, but it is against a 3-year old version, and is not a small patch. Hence I am reluctant to try to apply it myself. It is causing a problem in the Sage project, as I tried to compile Sage with Sun's compiler on Solaris, rather than gcc. |
|
|
| msg95629 - (view) |
Author: Michael Droettboom (mdboom) * |
Date: 2009-11-23 14:21 |
| This is a rather serious bug for matplotlib -- since the C++ compiler is not correctly selected, it can't be built with many Unix compilers, such as Sun Studio. |
|
|
| msg95631 - (view) |
Author: Tarek Ziadé (tarek) * |
Date: 2009-11-23 14:29 |
| Has someone tried to apply it with a recent Python ? I can work on it but I'll need some help from someone matplotlib or Sage I guess.. |
|
|
| msg95633 - (view) |
Author: Michael Droettboom (mdboom) * |
Date: 2009-11-23 15:43 |
| I'm testing this against release25_maint and release26_maint as we speak. I'll post new patches when that's done. |
|
|
| msg95640 - (view) |
Author: Michael Droettboom (mdboom) * |
Date: 2009-11-23 18:05 |
| Attached is a patch against the release26-maint branch. This works for me on Sun Workshop 6. Note that on Sun, the C compiler is 'cc' and the C++ compiler is 'CC', but distutils uses 'cc' and 'c++'. However, the CXX environment variable now works (after applying the patch), so this is less of an issue, if it can be considered a bug at all. |
|
|
| msg95641 - (view) |
Author: Michael Droettboom (mdboom) * |
Date: 2009-11-23 18:06 |
| Here's another patch against release25_maint for the benefit of those still using Python 2.5. It's different only in some whitespace changes. |
|
|
| msg100804 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) *  |
Date: 2010-03-10 19:26 |
| I'm attaching my own patch, which has the following advantages: - Determination of target language is performed per source file instead of per list of source files passed to CCompiler.compile(). - Proper determination of linker. - Proper support for CXXFLAGS and other variables. |
|
|
| msg100805 - (view) |
Author: Tarek Ziadé (tarek) * |
Date: 2010-03-10 19:59 |
| Moved to distutils2 (distutils is feature frozen now) |
|
|
| msg100806 - (view) |
Author: Michael Droettboom (mdboom) * |
Date: 2010-03-10 20:09 |
| Does the reassignment only apply to the more recent more ambitious patch? The original patch (and my forward porting of it) is purely a bugfix, not a feature freeze. This is a showstopper bug for matplotlib on Solaris, for example, and I would hate to see its application further delayed. |
|
|
| msg100807 - (view) |
Author: Tarek Ziadé (tarek) * |
Date: 2010-03-10 20:40 |
| If we consider that Distutils didn't provide c++ support, and that it partially worked by accident (through gcc), I would call it a new feature. Especially since it requires a new option. We are freezing the API so we can't add options to methods/functions. That's why it could be done on distutils2 instead, which will be released when 2.7 final is released (but not in the stdlib), and backward compatible with 2.4, 2.5, 2.6. If we could do the proper job for C++ support in distutils2 that would be better. Notice that distutils2 is a fork of how distutils was in trunk last month, so it should be fairly simple to depend on it in your project, to benefit from new features etc. The goal is to push it back in the stdlib in 3.3. If you want to start a dev. branch of your project using distutils2, I am willing to help there. |
|
|
| msg101588 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2010-03-23 17:28 |
| To have proper support for C++ linking in distutils2 at least in when used with Python 2.7, Makefile should set a variable, which will specify default C++ linker. I think that LDCXXSHARED can be used as a name for this new variable. I'm attaching the patch for configure.in and Makefile.pre.in. |
|
|
| msg101602 - (view) |
Author: Roumen Petrov (rpetrov) * |
Date: 2010-03-23 21:25 |
| I could not found reasons python build to support C++ compiler as all source is C! Another case is distutils where is possible external module to use C++ code. |
|
|
| msg101626 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2010-03-24 08:08 |
| Python can be compiled using C++ compiler. See http://docs.python.org/extending/extending.html#writing-extensions-in-c |
|
|
| msg101627 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2010-03-24 08:11 |
| Also you would have to pass --with-cxx-main= option to configure. |
|
|
| msg102216 - (view) |
Author: Benjamin Peterson (benjamin.peterson) * |
Date: 2010-04-03 01:58 |
| I think python-LDCXXSHARED.patch is fine. |
|
|
| msg102231 - (view) |
Author: Tarek Ziadé (tarek) * |
Date: 2010-04-03 08:47 |
| LDCXXSHARED added in r79652 and r79657. Now we can work on distutils2 side |
|
|
| msg115762 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2010-09-07 13:48 |
| Arfrever’s patch looks good. There is no tests for detect_language now; should the patch be blocked by that? (Note: Remember to use “hg import --user 'Arfrever Frehtes Taifersar Arahesis '” to give proper credit) |
|
|
| msg144117 - (view) |
Author: Dirkjan Ochtman (djc) * |
Date: 2011-09-16 09:25 |
| Could this get some attention, please? |
|
|
| msg144191 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2011-09-17 15:16 |
| Well, there’s no rush, Python 3.3b1 is not next week. I’m willing to apply the patch to packaging and distutils2 (in a week or two when I’ve finished a massive cleanup and caught up with packaging), but I’d like tests for detect_language, and if possible tests for compiling C++ extensions/libs too. |
|
|
| msg158200 - (view) |
Author: Dirkjan Ochtman (djc) * |
Date: 2012-04-13 08:13 |
| Ping, again. I'm sorry, I didn't write any of these patches and would not be a great fit for writing tests. |
|
|
| msg158223 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2012-04-13 18:00 |
| I should be able to port the patch and add tests for detect_language, but I know very little about C++ and may not be able to write a full test that really compiles and checks a C++ program. We’re having a sprint on the 21, I’ll see if I can work with another participant to do this. A sample short C++ source file would help (just use some Python/C function and print something). |
|
|
| msg178660 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2012-12-31 10:10 |
| I attach updated patches for distutils in case somebody wants to use them. (I privately update them once per week.) |
|
|
| msg213211 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2014-03-12 07:54 |
| Now that distutils2 development is stopped and that distutils is no longer under a feature freeze, this is a reasonable thing to add to 3.5. Thanks for your efforts Arfrever, and sorry you had to port and maintain this to so many different versions. |
|
|
| msg242706 - (view) |
Author: Erik Hvatum (ehvatum) |
Date: 2015-05-06 20:07 |
| The 2012-12-31 of this patch (currently the latest) has the surprising effect of causing distutils CFLAGS to be dropped. See for reference: https://bugs.gentoo.org/show_bug.cgi?id=548776 The issue I am experiencing is resolved by changing the section of the patch that reads: +- (cc, cxx, opt, cflags, ccshared, ldshared, shlib_suffix, ar, ar_flags) = \ +- get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS', +- 'CCSHARED', 'LDSHARED', 'SHLIB_SUFFIX', 'AR', 'ARFLAGS') ++ (cc, cxx, ccshared, ldshared, ldcxxshared, shlib_suffix, ar, ar_flags) = \ ++ get_config_vars('CC', 'CXX', 'CCSHARED', 'LDSHARED', 'LDCXXSHARED', ++ 'SHLIB_SUFFIX', 'AR', 'ARFLAGS') ++ ++ cflags = '' ++ cxxflags = '' to: +- (cc, cxx, opt, cflags, ccshared, ldshared, shlib_suffix, ar, ar_flags) = \ +- get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS', +- 'CCSHARED', 'LDSHARED', 'SHLIB_SUFFIX', 'AR', 'ARFLAGS') ++ (cc, cxx, cflags, ccshared, ldshared, ldcxxshared, shlib_suffix, ar, ar_flags) = \ ++ get_config_vars('CC', 'CXX', 'CFLAGS', 'CCSHARED', 'LDSHARED', 'LDCXXSHARED', ++ 'SHLIB_SUFFIX', 'AR', 'ARFLAGS') ++ ++ cxxflags = cflags This change causes the CFLAGS outputted by "python-config --cflags" to be used by distutils, as they are without the patch applied. To me, losing those CFLAGS, especially when building plain C python extensions, seems like a significant regression. |
|
|
| msg299396 - (view) |
Author: Josef Kemetmüller (Josef Kemetmüller) |
Date: 2017-07-28 15:29 |
| python-3.4-distutils-C++.patch with changes of Erik Hvatum applied. |
|
|
| msg299403 - (view) |
Author: Josef Kemetmüller (Josef Kemetmüller) |
Date: 2017-07-28 16:04 |
| python-3.4-distutils-C++.patch with Erik Hvatum's suggestions applied. |
|
|
| msg314859 - (view) |
Author: Ben Elliston (bje) |
Date: 2018-04-03 04:01 |
| Is there a simple workaround that one can put into setup.py in the meantime? I tried using compiler.compiler.remove('-Wstrict-prototypes') to no avail. |
|
|
| msg337380 - (view) |
Author: Jeroen Demeyer (jdemeyer) * |
Date: 2019-03-07 10:03 |
| > I tried using compiler.compiler.remove('-Wstrict-prototypes') to no avail. The -Wstrict-prototypes issue is a separate bug. It is fixed in Python >= 3.6 and there is an open backport PR for 2.7: https://github.com/python/cpython/pull/7476 |
|
|
| msg371688 - (view) |
Author: Ryan Schmidt (ryandesign) |
Date: 2020-06-16 18:22 |
| What needs to happen to get this 15 year old bug fixed? It prevents C++ Python modules from being compiled in situations where the user needs to supply CXXFLAGS. |
|
|
| msg371689 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2020-06-16 18:46 |
| Please report the issue with setuptools. distutils is no longer under development. We recommend that all users use setuptools. |
|
|
| msg371757 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2020-06-17 16:21 |
| > What needs to happen to get this 15 year old bug fixed? It prevents C++ Python modules from being compiled in situations where the user needs to supply CXXFLAGS. Someone has to propose a PR, someone else to review it, and a core developer has to take the responsibility to merge that PR. So far, there is no PR created. |
|
|
| msg371840 - (view) |
Author: Ryan Schmidt (ryandesign) |
Date: 2020-06-18 22:12 |
| Christian, thanks for the pointer. I think you're right, I probably am actually wanting this to be fixed in setuptools, not distutils, since setuptools is what people are using today. Since setuptools is an offshoot of distutils, I had assumed that the developers of setuptools would take ownership of any remaining distutils bugs that affected setuptools but I guess not. I looked through the setuptools issue tracker and this was the closest existing bug I could find: https://github.com/pypa/setuptools/issues/1732 |
|
|
| msg379348 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2020-10-22 21:08 |
| setuptools and other active build tools are the better target for this feature. |
|
|