[issue21401] python2 -3 does not warn about str to bytes conversions and comparisons
New submission from Joshua J Cogliati: The -3 option should warn about str to bytes conversions and str to bytes comparisons: For example in Python 3 the following happens: python3 Python 3.3.2 Type "help", "copyright", "credits" or "license" for more information. >>> b"a" + "a" Traceback (most recent call last): File "", line 1, in TypeError: can't concat bytes to str >>> b"a" == "a" False >>> But even python2 -3 does not warn about either of these uses: python2 -3 Python 2.7.5 Type "help", "copyright", "credits" or "license" for more information. >>> b"a" + "a" 'aa' >>> b"a" == "a" True >>> u"a" + "a" u'aa' >>> u"a" == "a" True >>> These two issues are some of the more significant problems I have in trying get python2 code working with python3, and if -3 does not warn about it this is harder to do. -- components: Unicode messages: 217633 nosy: Joshua.J.Cogliati, ezio.melotti, haypo priority: normal severity: normal status: open title: python2 -3 does not warn about str to bytes conversions and comparisons versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21401] python2 -3 does not warn about str/unicode to bytes conversions and comparisons
Joshua J Cogliati added the comment: Hm. That is a good point. Possibly it could only be done when from __future__ import unicode_literals has been used. For example: python2 -3 Python 2.7.5 Type "help", "copyright", "credits" or "license" for more information. >>> type(b"a") == type("a") True >>> from __future__ import unicode_literals >>> type(b"a") == type("a") False >>> b"a" == "a" True >>> b"a" + "a" u'aa' >>> After unicode_literals is used, then b"a" and "a" have a different type and the same code would be an issue in python3: python3 Python 3.3.2 >>> type(b"a") == type("a") False >>> b"a" == "a" False >>> b"a" + "a" Traceback (most recent call last): File "", line 1, in TypeError: can't concat bytes to str >>> -- ___ Python tracker <http://bugs.python.org/issue21401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7562] Custom order for the subcommands of build
Joshua J Cogliati added the comment: The documentation does claim that swig should just work "the build_ext command knows how to deal with SWIG extensions: it will run SWIG on the interface file and compile the resulting C/C++ file into your extension." It would be nice if there was one obvious way to compile a swig extension. (See for example the workarounds suggested in http://stackoverflow.com/questions/12491328 ) -- nosy: +Joshua.J.Cogliati ___ Python tracker <http://bugs.python.org/issue7562> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23644] swig compile fails with ‘_Atomic’ does not name a type
New submission from Joshua J Cogliati: The attached example works fine with Python 3.4.2, but fails with Python 3.5.0a1 and 3.5.0a2 I am using: $ g++ --version g++ (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6) $ swig -version SWIG Version 3.0.5 Compiled with g++ [x86_64-redhat-linux-gnu] Configured options: +pcre $ python3 --version Python 3.5.0a2 The output of trying the makefile with Python 3.5.0a2 is: $ make swig -c++ -python -py3 example.i g++ -g -fPIC -c example.cxx example_wrap.cxx -I/local/python350a2/include/python3.5m -I/local/python350a2/include/python3.5m In file included from /local/python350a2/include/python3.5m/pyatomic.h:10:0, from /local/python350a2/include/python3.5m/Python.h:53, from example_wrap.cxx:154: /usr/include/c++/4.9.2/exception:161:34: error: missing binary operator before token "(" #if (__cplusplus >= 201103L) && (ATOMIC_INT_LOCK_FREE > 1) ^ In file included from /local/python350a2/include/python3.5m/pyatomic.h:10:0, from /local/python350a2/include/python3.5m/Python.h:53, from example_wrap.cxx:154: /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:40:9: error: ‘_Atomic’ does not name a type typedef _Atomic _Bool atomic_bool; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:41:9: error: ‘_Atomic’ does not name a type typedef _Atomic char atomic_char; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:42:9: error: ‘_Atomic’ does not name a type typedef _Atomic signed char atomic_schar; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:43:9: error: ‘_Atomic’ does not name a type typedef _Atomic unsigned char atomic_uchar; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:44:9: error: ‘_Atomic’ does not name a type typedef _Atomic short atomic_short; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:45:9: error: ‘_Atomic’ does not name a type typedef _Atomic unsigned short atomic_ushort; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:46:9: error: ‘_Atomic’ does not name a type typedef _Atomic int atomic_int; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:47:9: error: ‘_Atomic’ does not name a type typedef _Atomic unsigned int atomic_uint; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:48:9: error: ‘_Atomic’ does not name a type typedef _Atomic long atomic_long; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:49:9: error: ‘_Atomic’ does not name a type typedef _Atomic unsigned long atomic_ulong; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:50:9: error: ‘_Atomic’ does not name a type typedef _Atomic long long atomic_llong; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:51:9: error: ‘_Atomic’ does not name a type typedef _Atomic unsigned long long atomic_ullong; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:52:9: error: ‘_Atomic’ does not name a type typedef _Atomic __CHAR16_TYPE__ atomic_char16_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:53:9: error: ‘_Atomic’ does not name a type typedef _Atomic __CHAR32_TYPE__ atomic_char32_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:54:9: error: ‘_Atomic’ does not name a type typedef _Atomic __WCHAR_TYPE__ atomic_wchar_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:55:9: error: ‘_Atomic’ does not name a type typedef _Atomic __INT_LEAST8_TYPE__ atomic_int_least8_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:56:9: error: ‘_Atomic’ does not name a type typedef _Atomic __UINT_LEAST8_TYPE__ atomic_uint_least8_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:57:9: error: ‘_Atomic’ does not name a type typedef _Atomic __INT_LEAST16_TYPE__ atomic_int_least16_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:58:9: error: ‘_Atomic’ does not name a type typedef _Atomic __UINT_LEAST16_TYPE__ atomic_uint_least16_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:59:9: error: ‘_Atomic’ does not name a type typedef _Atomic __INT_LEAST32_TYPE__ atomic_int_least32_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:60:9: error: ‘_Atomic’ does not name a type typedef _Atomic __UINT_LEAST32_TYPE__ atomic_uint_least32_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:61:9: error: ‘_Atomic’ does not name a type typedef _Atomic __INT_LEAST64_TYPE__ atomic_int_least64_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include/stdatomic.h:62:9: error: ‘_Atomic’ does not name a type typedef _Atomic __UINT_LEAST64_TYPE__ atomic_uint_least64_t; ^ /usr/lib/gcc/x86_64-redhat-linux/4.9.2/include
[issue23644] swig compile fails with ‘_Atomic’ does not name a type
Joshua J Cogliati added the comment: I have: /local/python_fix/include/python3.5m/pyatomic.h #ifndef Py_LIMITED_API #ifndef Py_ATOMIC_H #define Py_ATOMIC_H #include "dynamic_annotations.h" #include "pyconfig.h" #ifdef __cplusplus extern "C" { #endif #if defined(HAVE_STD_ATOMIC) #include #endif ... and still get: In file included from /local/python_fix/include/python3.5m/pyatomic.h:14:0, from /local/python_fix/include/python3.5m/Python.h:53, from example_wrap.cxx:154: /usr/include/c++/4.9.2/exception:161:34: error: missing binary operator before token "(" #if (__cplusplus >= 201103L) && (ATOMIC_INT_LOCK_FREE > 1) So the bug still seems to be there. -- ___ Python tracker <http://bugs.python.org/issue23644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23644] g++ module compile fails with ‘_Atomic’ does not name a type
Joshua J Cogliati added the comment: If I change the header to: #ifndef Py_LIMITED_API #ifndef Py_ATOMIC_H #define Py_ATOMIC_H #include "dynamic_annotations.h" #include "pyconfig.h" #ifdef __cplusplus extern "C" { #endif #if defined(HAVE_STD_ATOMIC) #ifdef __cplusplus #include using namespace std; #else #include #endif #endif ... (rest same) AND use -std=c++11 Then the error changes to: In file included from /local/python_fix/include/python3.5m/Python.h:53:0, from example_wrap.cxx:154: /local/python_fix/include/python3.5m/pyatomic.h:42:5: error: ‘_Atomic’ does not name a type _Atomic void *_value; ^ Basically, does define std::atomic_int, but it does not define _Atomic, so the line: _Atomic void *_value; will also need to be changed. -- title: swig compile fails with ‘_Atomic’ does not name a type -> g++ module compile fails with ‘_Atomic’ does not name a type ___ Python tracker <http://bugs.python.org/issue23644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23644] g++ module compile fails with ‘_Atomic’ does not name a type
Joshua J Cogliati added the comment: >> using namespace std; >Doing this in a header is ugly. If you put it in the: #ifdef __cplusplus extern "C" { #endif then it would only apply till the end of the pyatomic header, and not to anything that includes it. Something like: #ifdef __cplusplus extern "C" { #if defined(HAVE_STD_ATOMIC) using namespace std; #endif #endif But if you are already defining: #define _Atomic(T) atomic maybe it should be: #define _Atomic(T) std::atomic (I haven't checked any of this code, but they would get around the namespace std being changed in code that includes pyatomic.h problem. ) -- ___ Python tracker <http://bugs.python.org/issue23644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23644] g++ module compile fails with ‘_Atomic’ does not name a type
Joshua J Cogliati added the comment: >Hum, I'm lost with the problem with C++ :-( What is your use case? Do >you >want to compile CPython with C++? Or compile a third-party >extension with C++ >and this extension includes "Python.h" which >includes "pyatomic.h". My use case is I have C++ code that I want to use from a extension. The extension includes Python.h, which includes pyatomic.h. Thank you for looking into this. -- ___ Python tracker <http://bugs.python.org/issue23644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23644] g++ module compile fails with ‘_Atomic’ does not name a type
Joshua J Cogliati added the comment: > @Joshua: Can you please try to compile your extension with Py_LIMITED_API > defined? Ex: "#define Py_LIMITED_API 0x0303" at the top of your C file, > or g++ -DPy_LIMITED_API=0x0303. It fails in that case, because SWIG is using functions that are not part of the Py_LIMITED_API. > And can you also please try to patch Python with pystate_cplusplus.patch? With the pystate_cplusplus.patch I was able to compile both min_example.tar.gz and my actual extension. So I with your patch, it does work. Thank you. -- ___ Python tracker <http://bugs.python.org/issue23644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache
Joshua J Cogliati added the comment: This bug is still in Python 3.5.0a2 (but first issue 23644 needs to be fixed before g++ can be used at all) Attached is a patch for Python 3.5.0. -- versions: +Python 3.5 Added file: http://bugs.python.org/file38530/fix-distutils-350.patch ___ Python tracker <http://bugs.python.org/issue8027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23644] g++ module compile fails with ‘_Atomic’ does not name a type
Joshua J Cogliati added the comment: Once this is fixed, maybe issue 8027 can be fixed as well in 3.5.0. -- ___ Python tracker <http://bugs.python.org/issue23644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache
Joshua J Cogliati added the comment: Here is an example to use to test for this bug. Proper use on my computer (PYTHONPATH may need adjusting on other systems): Python2: cd small_example python setup.py build_ext build install --prefix=`pwd` export PYTHONPATH=`pwd`/lib64/python2.7/site-packages cd test python a_test.py # outputs 3 Python3: cd small_example python3 setup.py build_ext build install --prefix=`pwd` export PYTHONPATH=`pwd`/lib64/python3.4/site-packages cd test python3 a_test.py # outputs 3 Clean files: rm -Rf build/ lib/ lib64/ example/example.py example/example_wrap.cpp *~ example/__pycache__/ Check for the bug: export CXX="env BAR=FOO g++" or export CXX="ccache g++" etc Then run either the Python2 or Python3 test, and it will fail if this bug has not been fixed. -- nosy: +haypo Added file: http://bugs.python.org/file38544/small_example.tar.gz ___ Python tracker <http://bugs.python.org/issue8027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache
Joshua J Cogliati added the comment: > Does the patch fix things on Mac OS X and Linux? So far as I can tell, the code in question is to do something so that CXX variables like: export CXX="env BAR=FOO g++" work better. However, it is broken for that case, and since it has been broken since at least python 2.6, I think it would be better to remove the code, as my patches do. My patches do fix things for me on Linux on my case of: export CXX="ccache g++" and do not make things worse for the env case. I can check on OSX if you like. -- ___ Python tracker <http://bugs.python.org/issue8027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache
Joshua J Cogliati added the comment: On OSX 10.10.1, With the small_example, and with python 3.4.3 and: $ export CXX="env BAR=FOO g++" $ python3 setup.py build_ext build install --prefix=`pwd` running build_ext building '_example' extension swigging example/example.i to example/example_wrap.cpp swig -python -c++ -py3 -Iexample -o example/example_wrap.cpp example/example.i creating build creating build/temp.macosx-10.10-x86_64-3.4 creating build/temp.macosx-10.10-x86_64-3.4/example gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iexample -I/Users/jjc/bug/py343/include/python3.4m -c example/example_wrap.cpp -o build/temp.macosx-10.10-x86_64-3.4/example/example_wrap.o gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iexample -I/Users/jjc/bug/py343/include/python3.4m -c example/example.cxx -o build/temp.macosx-10.10-x86_64-3.4/example/example.o creating build/lib.macosx-10.10-x86_64-3.4 creating build/lib.macosx-10.10-x86_64-3.4/example env -bundle -undefined dynamic_lookup build/temp.macosx-10.10-x86_64-3.4/example/example_wrap.o build/temp.macosx-10.10-x86_64-3.4/example/example.o -o build/lib.macosx-10.10-x86_64-3.4/example/_example.so env: illegal option -- b usage: env [-i] [name=value ...] [utility [argument ...]] error: command 'env' failed with exit status 1 So, as is, python 3.4.3 fails. With the same as above, but with the fix-distutils-342.patch applied: $ export CXX="env BAR=FOO g++" $ python3 setup.py build_ext build install --prefix=`pwd` running build_ext building '_example' extension swigging example/example.i to example/example_wrap.cpp swig -python -c++ -py3 -Iexample -o example/example_wrap.cpp example/example.i creating build creating build/temp.macosx-10.10-x86_64-3.4 creating build/temp.macosx-10.10-x86_64-3.4/example gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iexample -I/Users/jjc/bug/py343m/include/python3.4m -c example/example_wrap.cpp -o build/temp.macosx-10.10-x86_64-3.4/example/example_wrap.o gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Iexample -I/Users/jjc/bug/py343m/include/python3.4m -c example/example.cxx -o build/temp.macosx-10.10-x86_64-3.4/example/example.o creating build/lib.macosx-10.10-x86_64-3.4 creating build/lib.macosx-10.10-x86_64-3.4/example gcc -bundle -undefined dynamic_lookup build/temp.macosx-10.10-x86_64-3.4/example/example_wrap.o build/temp.macosx-10.10-x86_64-3.4/example/example.o -o build/lib.macosx-10.10-x86_64-3.4/example/_example.so running build running build_py copying example/example.py -> build/lib.macosx-10.10-x86_64-3.4/example copying example/__init__.py -> build/lib.macosx-10.10-x86_64-3.4/example running install running install_lib creating /Users/jjc/bug/small_example/lib creating /Users/jjc/bug/small_example/lib/python3.4 creating /Users/jjc/bug/small_example/lib/python3.4/site-packages creating /Users/jjc/bug/small_example/lib/python3.4/site-packages/example copying build/lib.macosx-10.10-x86_64-3.4/example/__init__.py -> /Users/jjc/bug/small_example/lib/python3.4/site-packages/example copying build/lib.macosx-10.10-x86_64-3.4/example/_example.so -> /Users/jjc/bug/small_example/lib/python3.4/site-packages/example copying build/lib.macosx-10.10-x86_64-3.4/example/example.py -> /Users/jjc/bug/small_example/lib/python3.4/site-packages/example byte-compiling /Users/jjc/bug/small_example/lib/python3.4/site-packages/example/__init__.py to __init__.cpython-34.pyc byte-compiling /Users/jjc/bug/small_example/lib/python3.4/site-packages/example/example.py to example.cpython-34.pyc running install_egg_info Writing /Users/jjc/bug/small_example/lib/python3.4/site-packages/example-0.5-py3.4.egg-info $ export PYTHONPATH=`pwd`/lib/python3.4/site-packages $ cd test $ python3 a_test.py 3 So with the patch, it succeeds. > Does the patch fix things on Mac OS X and Linux? Yes. -- ___ Python tracker <http://bugs.python.org/issue8027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache
Joshua J Cogliati added the comment: Looking at the patch (3078fdb7cf3d for Issue1488098) it has: if target_lang == "c++" and self.compiler_cxx: -linker[0] = self.compiler_cxx[0] One possibility is that that the problem was: linker[0] = self.compiler_cxx[0] which would also cause a compiler_cxx like: export CXX="env BAR=FOO g++" to fail. Possibly the code: linker[i] = self.compiler_cxx[i] managed to hit on an index value that worked better for the CXX that Ronald had on his system. I think the root cause is the special casing of if target_lang == "c++" and self.compiler_cxx: and I think that few enough people use a c++ for extensions and of those, most use CXX="g++" or something similar where the complicated but incorrect version that is in Python works. Basically, if you have something like CXX="g++" then both the version before 3078fdb7cf3d and after 3078fdb7cf3d work. If you have something like CXX="env BAR=FOO g++" then the version before 3078fdb7cf3d would not have worked. I think it is likely that if 3078fdb7cf3d had completely eliminated: -if target_lang == "c++" and self.compiler_cxx: -linker[0] = self.compiler_cxx[0] instead of adding new code to try and work around the problem it also would have fixed the problem that Issue1488098 encountered. I am guessing this problem really started with changeset 771b6f521b95 in 2002. This codes purpose is: (UnixCCompiler.link): Included target_lang parameter, and made linker command use compiler_cxx, if target_lang is 'c++'. and that change is the one that added: linker[0] = self.compiler_cxx[0] -- ___ Python tracker <http://bugs.python.org/issue8027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache
Joshua J Cogliati added the comment: Let me try and explain what is trying to be done in the original code, what the fix was, and then discuss some possible better solutions. Original code: if target_lang == "c++" and self.compiler_cxx: linker[0] = self.compiler_cxx[0] Current code: if target_lang == "c++" and self.compiler_cxx: i = 0 if os.path.basename(linker[0]) == "env": i = 1 while '=' in linker[i]: i += 1 linker[i] = self.compiler_cxx[i] Basically, what we have, is two variables, linker, and self.compiler_cxx. By default on my linux system these are: linker=['gcc', '-pthread', '-shared'] self.compiler_cxx=['g++', '-pthread'] So under the current code, since self.compiler_cxx[0] != "env" i=0 so linker[0] = self.compiler_cxx[0] so linker=['g++', '-pthread', '-shared'] So the goal is to switch the linker to something that works better with c++. In the original code: linker[0] = self.compiler_cxx[0] improves things if the first element in the linker variable is the linker executable, and the first element in compiler_cxx is a compiler executable, and the compiler executable works better at linking c++ code than the c linker executable. Next we switch to the current code. I am guessing that Ronald had something like this: linker=['env','BAR=FOO','gcc', '-pthread', '-shared'] self.compiler_cxx=['env','BAR=FOO','g++', '-pthread'] and so with the current code we end up with i=2, and the linker variable ends up with: linker=['env','BAR=FOO','g++', '-pthread', '-shared'] Now, what is the problem we are encountering with the current code? Basically, people want to use things like CXX="ccache g++" So if linker=['gcc', '-pthread', '-shared'] self.compiler_cxx=['ccache', 'g++'] we have i=0, linker[0]=self.compiler_cxx[0] = 'ccache' resulting in linker=['ccache', '-pthread', '-shared'] which will fail, because ccache expects the first argument to be the compiler executable (that is 'g++' not '-pthread') So, how can we fix this? If the linker can link c++ code, then the optimal solution is to do nothing, as in remove the entire if target_lang == "c++" and self.compiler_cxx: ... (The fix-distutils-* patches I have created do this solution) We could special case ccache: if target_lang == "c++" and self.compiler_cxx: if os.path.basename(self.compiler_cxx[0]) == "ccache": linker[0:1] = self.compiler_cxx[0:2] elif os.path.basename(linker[0]) == "env": ... We could hope that what we actually want is the entire compiler_cxx: if target_lang == "c++" and self.compiler_cxx: linker[0:1] = self.compiler_cxx[:] Maybe we could special case c++ a little earlier (since linker_exe is just cc by default): if target_desc == CCompiler.EXECUTABLE and target_lang == "c++" and self.compiler_cxx: linker = self.compiler_cxx[:] elif target_desc == CCompiler.EXECUTABLE: linker = self.linker_exe[:] else: linker = self.linker_so[:] None of these solutions make me feel awesome. The real problem is that we have no way to set the c++ linker. I don't see any variable listed like this Make's implicit variables section. A secondary problem is that we string concatenate the LDSHARED and LDFLAGS (in the line: ldshared = ldshared + ' ' + os.environ['LDFLAGS'] in sysconfig.py) Another secondary problem is that we don't look for a CXXFLAGS varible, and so people stuff parameters into CXX instead. If the two secondary issues did not exist we could reasonably reliably do something like linker = cxx + ldflags which might actually work for all the cases that are currently covered and work where cxx=['ccache','g++'] The current code is broken, how do we want to fix it? -- ___ Python tracker <http://bugs.python.org/issue8027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache
Joshua J Cogliati added the comment: I looked and the autoconf variable for the c++ linker is CXXLINK, so I think the proper way to fix this would be to change sysconfig.py to look at both CXXFLAGS and CXXLINK, and create those and use it to define a cxxlink variable, and only if they are missing should we actually try to do some of the magic that is currently used. Also, my patches (fix-distutils-*.patch) do not always work, because sometimes the c compiler cannot link the c++ code. -- ___ Python tracker <http://bugs.python.org/issue8027> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com