[issue21401] python2 -3 does not warn about str to bytes conversions and comparisons

2014-04-30 Thread Joshua J Cogliati 

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 snip
Type help, copyright, credits or license for more information.
 ba + a
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: can't concat bytes to str
 ba == a
False
 

But even python2 -3 does not warn about either of these uses:

python2 -3
Python 2.7.5 snip
Type help, copyright, credits or license for more information.
 ba + a
'aa'
 ba == a
True
 ua + a
u'aa'
 ua == 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 rep...@bugs.python.org
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

2014-05-01 Thread Joshua J Cogliati 

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 snip
Type help, copyright, credits or license for more information.
 type(ba) == type(a)
True
 from __future__ import unicode_literals
 type(ba) == type(a)
False
 ba == a
True
 ba + a
u'aa'
 


After unicode_literals is used, then ba and a have a different type and the 
same code would be an issue in python3:
 python3
Python 3.3.2 snip
 type(ba) == type(a)
False
 ba == a
False
 ba + a
Traceback (most recent call last):
  File stdin, line 1, in module
TypeError: can't concat bytes to str


--

___
Python tracker rep...@bugs.python.org
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

2014-11-05 Thread Joshua J Cogliati 

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 rep...@bugs.python.org
http://bugs.python.org/issue7562
___
___
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

2015-03-18 Thread Joshua J Cogliati 

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 rep...@bugs.python.org
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

2015-03-18 Thread Joshua J Cogliati 

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 rep...@bugs.python.org
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

2015-03-16 Thread Joshua J Cogliati 

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) atomicT
maybe it should be:
#define _Atomic(T) std::atomicT

(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 rep...@bugs.python.org
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

2015-03-17 Thread Joshua J Cogliati 

Joshua J Cogliati added the comment:

Once this is fixed, maybe issue 8027 can be fixed as well in 3.5.0.

--

___
Python tracker rep...@bugs.python.org
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

2015-03-17 Thread Joshua J Cogliati 

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 rep...@bugs.python.org
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

2015-03-17 Thread Joshua J Cogliati 

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 rep...@bugs.python.org
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

2015-03-17 Thread Joshua J Cogliati 

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 rep...@bugs.python.org
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

2015-03-18 Thread Joshua J Cogliati 

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 rep...@bugs.python.org
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] swig compile fails with ‘_Atomic’ does not name a type

2015-03-12 Thread Joshua J Cogliati 

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/stdatomic.h:63:9: error: 
‘_Atomic

[issue23644] swig compile fails with ‘_Atomic’ does not name a type

2015-03-12 Thread Joshua J Cogliati 

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 stdatomic.h
#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 rep...@bugs.python.org
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

2015-03-12 Thread Joshua J Cogliati 

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 atomic
using namespace std;
#else
#include stdatomic.h
#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, atomic 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 rep...@bugs.python.org
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

2015-03-19 Thread Joshua J Cogliati 

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 rep...@bugs.python.org
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

2015-04-02 Thread Joshua J Cogliati 

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 rep...@bugs.python.org
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

2015-04-08 Thread Joshua J Cogliati 

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 rep...@bugs.python.org
http://bugs.python.org/issue8027
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com