I am developing a set of extension modules for python written in C++ and have successfully written a setup.py that works on my mac. Portability is important, though, and under Linux, the linking command I get from distutils appears to be not what I want. Specifically, on the mac, the compile command from distutils is gcc with the appropriate command line options and the link command is c++. On the Linux machine, gcc is both the compile and linking command, and when the module is loaded, I get ImportError: ../build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so: undefined symbol: endl__FR7ostream which sure looks like a missing c++ library to me. In my searching through distutils documentation, all I can find is a warning to "Be sure to use appropriate extensions to distinguish C++ source files: .cc and .cpp seem to be recognized by both Unix and Windows compilers." But changing my suffix from .cxx to .cpp didn't help. (I was using .cxx because that is the default suffix produced by SWIG -- but I'm currently calling swig via a Makefile because distutils doesn't appear to be robust enough yet to handle everything I need it to do.) System info: sahp4960(41)$ uname -a Linux sahp4960 2.4.18-17.7.xsmp #1 SMP Tue Oct 8 12:37:04 EDT 2002 i686 unknown Python info: sahp4960(42)$ python Python 2.2.1 (#1, May 14 2002, 16:46:34) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 [It just occurred to me that this could be a python version issue, as my working mac version is under python 2.3. I'll be looking into this, but would still appreciate a response.] Thanks ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wfspotz@sandia.gov **
ImportError: ../build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so: undefined symbol: endl__FR7ostream
which sure looks like a missing c++ library to me.
Well, a linking problem anyway. according to c++filt: endl(long double, ostream) I'm not that much of a c++ expert, but this looks like a non-standard overload of endl, is that maybe provided by some of /your/ code and not getting linked in?
On Friday, January 9, 2004, at 11:42 PM, Mats Wichmann wrote:
ImportError: ../build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so: undefined symbol: endl__FR7ostream
which sure looks like a missing c++ library to me.
Well, a linking problem anyway.
according to c++filt: endl(long double, ostream)
I'm not that much of a c++ expert, but this looks like a non-standard overload of endl, is that maybe provided by some of /your/ code and not getting linked in?
Hmmm. On the system where I'm getting the problem, I get sahp4960(1)$ c++filt endl__FR7ostream endl(ostream &) which looks like the standard definition of endl. Interestingly, on my mac, I get samt5735a(29)$ c++filt endl__FR7ostream long double which looks like some type of misinterpretation (the "l" at the end of "endl" wrongly interpreted as a long modifier? I don't know). But if I use c++filt's "standard input mode", I get samt5735a(33)$ c++filt endl__FR7ostream # Standard input endl(ostream &) # Standard output Ctrl-D Anyway, I'm pretty sure endl__FR7ostream gets demangled as endl(ostream &), and while I am not a primary developer of the software I am trying to wrap, I'd be very surprised if this gets overloaded somewhere (at least, a cursory search using grep didn't turn anything up). Here is the link line generated by distutils on the Linux platform: gcc -shared build/temp.linux-i686-2.2/Epetra_wrap.o -LCommon -L/usr/netpub/Trilinos-10_31_03/lib -L/usr/netpub/swig-1.3.19/lib -L/usr/local/python-2.2.1/lib/python2.2/config -lcommon -lswigpy -lepetra -lblas -llapack -lg2c -lpython2.2 -o build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so What surprises me is that the command is gcc rather than c++ (as it is on the mac) and that, given this fact, there are no c++ libraries included in the command line. ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wfspotz@sandia.gov **
On Monday, January 12, 2004, at 09:55 AM, Bill Spotz wrote:
Here is the link line generated by distutils on the Linux platform:
gcc -shared build/temp.linux-i686-2.2/Epetra_wrap.o -LCommon -L/usr/netpub/Trilinos-10_31_03/lib -L/usr/netpub/swig-1.3.19/lib -L/usr/local/python-2.2.1/lib/python2.2/config -lcommon -lswigpy -lepetra -lblas -llapack -lg2c -lpython2.2 -o build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so
What surprises me is that the command is gcc rather than c++ (as it is on the mac) and that, given this fact, there are no c++ libraries included in the command line.
OK, on the PythonMac-SIG list, Jack Jansen wrote
Distutils doesn't properly support C++ until Python 2.3; for earlier versions you have to do various bizarre things to force it to link on various platforms.
Which would seem to be the answer to my problem. And in fact, upgrading to python 2.3 and recompiling, the link command from distutils changes from gcc to c++, which is what I was hoping for. Now it is not finding SWIG_TypeClientData, so I may be switching over to a SWIG mailing list. ** Bill Spotz ** ** Sandia National Laboratories Voice: (505)845-0170 ** ** P.O. Box 5800 Fax: (505)284-5451 ** ** Albuquerque, NM 87185-0316 Email: wfspotz@sandia.gov **
C++ standard? Hah. I guess I've got an odd one here...
Here is the link line generated by distutils on the Linux platform:
gcc -shared build/temp.linux-i686-2.2/Epetra_wrap.o -LCommon -L/usr/netpub/Trilinos-10_31_03/lib -L/usr/netpub/swig-1.3.19/lib -L/usr/local/python-2.2.1/lib/python2.2/config -lcommon -lswigpy -lepetra -lblas -llapack -lg2c -lpython2.2 -o build/lib.linux-i686-2.2/PyTrilinos/_Epetra.so
What surprises me is that the command is gcc rather than c++ (as it is on the mac) and that, given this fact, there are no c++ libraries included in the command line.
Some people try to link without the full C++ library. I've seen programs that use gcc and link with libsupc++, which is supposed to work, but I don't /think/ gcc will put that library in for you by magic. All of which doesn't seem to be helping your problem. Is there any way to force it to try g++ instead of gcc?
participants (2)
-
Bill Spotz -
Mats Wichmann