[Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions
noreply@sourceforge.net
noreply@sourceforge.net
Tue, 05 Nov 2002 08:15:54 -0800
Bugs item #413582, was opened at 2001-04-04 00:42
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470
Category: Distutils
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Gustavo Niemeyer (niemeyer)
Summary: g++ must be called for c++ extensions
Initial Comment:
When building c++ extension using distutils setup,
the compiler that was used to build python distribution
is always called. On Linux, it is normally gcc.
When gcc is called to link shared library, it does not
link certain c++ runtime stuff. As a result, when
extension is imported, missing symbols are reported,
e.g.:
>>> import ex_ext1
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: ./ex_ext1.so: undefined symbol:
__vt_13runtime_error
>>>
I tried to use "extra_link_args = ['-x c++']" in
setup.py (it tells gcc to link as c++), but that gets
added to the end of compiler's command line, which
results in:
gcc -shared build/temp.linux-i686-2.1/ex_ext1.o
-L../boost/libs/python -lboost_python -o
build/lib.linux-i686-2.1/ex_ext1.so -x c++
gcc: Warning: `-x c++' after last input file has no
effect
Proposed solution: either use CXX= variable from Python
Makefile when c++ files are involved, or prepend
extra_link_args to compiler's arguments instead of
appending them.
----------------------------------------------------------------------
>Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-11-05 16:15
Message:
Logged In: YES
user_id=7887
Applied as:
bcppcompiler.py:1.13->1.14
ccompiler.py:1.49->1.50
cygwinccompiler.py:1.18->1.19
emxccompiler.py:1.8->1.9
extension.py:1.12->1.13
msvccompiler.py:1.49->1.50
mwerkscompiler.py:1.10->1.11
sysconfig.py:1.51->1.52
unixccompiler.py:1.48->1.49
command/build_ext.py:1.87->1.88
command/config.py:1.12->1.13
Thank you!
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-11-05 12:53
Message:
Logged In: YES
user_id=21627
This patch looks fine, please apply it. If you have spare
time, please check out the distutils CVS module, and see
whether the tests still pass.
----------------------------------------------------------------------
Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-11-05 12:42
Message:
Logged In: YES
user_id=7887
(I just realized I posted the patch to this bug, and not the
one I told. Sorry)
Ok.. I'm attaching a new patch including your suggestions. A
few comments:
- Instead of setting cpp_linker, I'm now using compiler_cxx,
as that's what it
really is right now, from a Makefile point of view. Other
compilers may want
to use it in different places.
- I'm now checking if compiler_cxx is set before using it.
In the worst case,
the old behavior will be used, hoping for the best.
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-11-05 08:12
Message:
Logged In: YES
user_id=21627
A couple of comments:
- distutils should stay compatible with earlier versions of
Python,
back to 1.5.2. So don't use isinstance(value, list), as
list might
be a function
- cpp_ might be confused as having to do with the
preprocessor; I recommend to use cxx_ throughout
- You should check whether CXX is set. If it isn't, and you
need to compile a C++ file, you should probably raise an
exception.
----------------------------------------------------------------------
Comment By: Gustavo Niemeyer (niemeyer)
Date: 2002-11-05 02:19
Message:
Logged In: YES
user_id=7887
I'm attaching a proposed solution.
Here is how the magic is done:
There's a new CCompiler.detect_language() method, which
based on the sources extensions and on language_map and
language_order class variables (subclasses can overload
these), determine what's the "target language" of a set of
source files. This target language is passed to every
CCompiler method which deals with the linkage step
(create_static_lib(), link(), and link_*()).
UnixCCompiler uses this information to replace the linking
command (if the target language is c++) with cpp_linker[0],
which is set on sysconfig.py:customize_compiler().
Other classes, such as msvccompiler.py, could also use the
same infrastructure
to remove some of the hardcoded extension tests already there.
Additionally, an Extension can set the "language" parameter
to hardcode a language in setup.py.
(PS. this patch also fixes some wrong prototypes of
create_static_libs())
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-18 12:55
Message:
Logged In: YES
user_id=6380
reassigned to amk who should know
----------------------------------------------------------------------
Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 06:47
Message:
Logged In: YES
user_id=29957
can this be closed as a duplicate of 454030? That one
has a real submitter, and some more info...
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 15:51
Message:
Logged In: YES
user_id=6380
Assigning this to Andrew, who is the current distutils
maintainer.
----------------------------------------------------------------------
Comment By: Andrei Tovtchigretchko (andreitd)
Date: 2001-04-05 00:23
Message:
Logged In: YES
user_id=189208
Follow-up:
If I link with a static library (-lboost_python is
libboost_python.a in bug post example), the problem shows.
If I link with shared c++ library (libboost_python.so),
everything is ok.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470