[Python-bugs-list] [ python-Bugs-433481 ] No way to link python itself with C++

[noreply@sourceforge.net]

Bugs item #433481, was opened at 2001-06-15 10:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433481&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Stephan A. Fiedler (sfiedler)
Assigned to: Nobody/Anonymous (nobody)
Summary: No way to link python itself with C++

Initial Comment:
I'm running on Solaris 2.7 with the Sun Workshop
compiler, version 4.2.

I have built an extension module in C++ as a shared
object. When I attempt to import it into Python, I get
an error about missing symbols related to C++ exception
handling:

ImportError: ld.so.1: python: fatal: relocation error:
file
/home/saf/pymidas/m2k/solaris_debug/comp/m2kapi.so:
symbol _ex_keylock: referenced symbol not found

This symbol lives in the C++ runtime, libC.so. 'ldd
python' shows that this library is not available to the
Python executable itself, because the C compiler linked
the executable.

If I manually edit the makefile for building python so
that LINKCC is 

$(PURIFY) $(CXX) 

instead of 

$(PURIFY) $(CC)

and then relink just the Python executable, I can see
(with ldd) that the C++ runtime libC.so is now linked
with Python, and I am able to load my module. (I
believe it is actually no problem to build the entire
system with LINKCC calling CXX instead of CC.)

In case it's relevant, my extension module itself is
compiled with these flags:

-DDEBUG -DSUNCC_ -mt -pto -PIC -xildoff +w2
-D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64

and linked with these:

-G -z text

Bug #413582 may be related to this in some way.


So the short of it is that I would like a configure
option to link the final python executable using the
C++ compiler on Solaris, so that I can get the C++
runtime linked in with python itself.

Note that this doesn't seem to matter on Compaq Tru64
Unix systems, where the default Python build works just
fine with my extension module.

----------------------------------------------------------------------

>Comment By: Stephan A. Fiedler (sfiedler)
Date: 2001-06-25 13:12

Message:
Logged In: YES 
user_id=246063

Using LINKCC=CC on the configure line worked perfectly for
us. Thanks for the tip. (I changed the bug state to closed;
don't know if I'm the one who was supposed to do that, but I
am no longer troubled by this circumstance.)

----------------------------------------------------------------------

Comment By: Stephan A. Fiedler (sfiedler)
Date: 2001-06-18 11:18

Message:
Logged In: YES 
user_id=246063

I should have given the full link line like this:

CC -G -z text -o pyapi_launch.so  $(OTHER_LIBS) -xildoff
-ldl -lposix4 -lnsl -lsocket -lfftw_threads -lrfftw_threads
-lfftw -lrfftw -lreadline -ltermcap

$(OTHER_LIBS) just expands to a bunch of .so's that were
themselves linked in the same way. pyapi_launch.so is my
extension module. 

This does not solve the problem.

The news about LINKCC is delightful. To make sure I
understand, is it merely (csh syntax):

<configure Python>
setenv LINKCC CC
make

? Or would I also/instead need to do

/bin/env LINKCC=CC ./configure ...
make

? This may well be all I need.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-06-16 01:03

Message:
Logged In: YES 
user_id=21627

I believe the right fix to your problem would be to link 
your extension module using CC, not using ld. In theory, 
that should provide all required libraries to the shared 
object itself. Please report whether this solves the 
problem.

As for the configure option: This is already configurable. 
Just set LINKCC when making python.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433481&group_id=5470