This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: LINKCC incorrect
Type: Stage:
Components: Build Versions: Python 2.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: cludwig, loewis
Priority: normal Keywords:

Created on 2005-04-25 09:01 by cludwig, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
python-configure.patch cludwig, 2005-05-03 08:29 Patch against revision 1.484 of configure.in
Messages (4)
msg25110 - (view) Author: Christoph Ludwig (cludwig) Date: 2005-04-25 09:01
I configured Python 2.4.1 as follows 
 
../Python-2.4.1/configure \ 
    --prefix=/home/cludwig/C++/gcc4.0/Python-2.4.1 \ 
    --with-cxx=/opt/gcc/gcc-4.0.0/bin/g++ --enable-shared \ 
    --enable-unicode --with-signal-module \ 
    --with-universal-newlines --with-doc-strings  
 
on a i686-pc-linux-gnu system. make fails when linking the 
python binariy due to an undefined reference to 
`__gxx_personality_v0'. In fact, configure set 
 
  CC=             gcc -pthread 
  CXX=            /opt/gcc/gcc-4.0.0/bin/g++ -pthread 
  LINKCC=         $(PURIFY) $(CC) 
 
but the python executable needs to be linked with $(CXX). 
(Note the `--with-cxx' option in the configure command line.) 
 
I did not observe this problem with Python 2.4.0 / gcc 3.4.2. 
This seems to be a regression w.r.t. PR #569668 that was 
closed as fixed on 2002-12-03. 
 
I can submit config.log and the output of make on request. 
 
Regards 
 
Christoph 
msg25111 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-05-02 21:13
Logged In: YES 
user_id=21627

Can you propose a patch?
msg25112 - (view) Author: Christoph Ludwig (cludwig) Date: 2005-05-03 08:29
Logged In: YES 
user_id=1266029

That depends on how clever the patch is supposed to be. 
 
I am going to attach a patch against configure.in (from current 
CVS) that enforces `LINKCC = $(PURIFY) $(CXX)' if 
--with-cxx=<comiler> is passed to configure. My rationale is that a 
user who specifies --with-cxx wants python to be build with the 
C++ compiler and therefore won't mind if the executable depends 
on the C++ runtime library. 
 
The previous code in configure.in tried to determine if one can 
link the executable with the C compiler/linker even if some of the 
object files were compiled by a C++ compiler. The approach 
taken seems to be fragile, though: In simple cases g++ 4.0 seems 
to realize there is no need for the C++ runtime libraries, but in 
more complex cases it adds a dependency on the C++ runtime 
anyway. Even if you add a more complex test case to 
configure.in, how do you know your testcase mirrors the 
complexity of the python executable and any C++ extension 
loaded at runtime? I think a proper test would be quite involved 
whence I prefer the simplistic approach taken by my patch. 
 
Do you know a system / use case where one needs to compile 
python.c with a C++ compiler but needs to avoid the dependency 
on the C++ runtime? 
 
Regards 
 
Christoph 
msg25113 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-08-07 21:10
Logged In: YES 
user_id=21627

This is fixed with #1239112.
History
Date User Action Args
2022-04-11 14:56:11adminsetgithub: 41894
2005-04-25 09:01:07cludwigcreate