[Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions

noreply@sourceforge.net noreply@sourceforge.net
Mon, 04 Nov 2002 18:19:31 -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: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
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 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