Issue1189330
Created on 2005-04-25 09:01 by cludwig, last changed 2005-08-07 21:10 by loewis.
| File name |
Uploaded |
Description |
Edit |
Remove |
|
python-configure.patch
|
cludwig,
2005-05-03 08:29
|
Patch against revision 1.484 of configure.in |
|
|
|
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) |
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) |
Date: 2005-08-07 21:10 |
|
Logged In: YES
user_id=21627
This is fixed with #1239112.
|
|
| Date |
User |
Action |
Args |
| 2005-04-25 09:01:07 | cludwig | create | |
|