[SciPy-user] Scipy weave errors: undefined symbols when importing compiled extension

Craig Finch oanjao@yahoo....
Fri Jul 3 13:38:06 CDT 2009

Thank you for the suggestion.  I have some new information, but unfortunately no solution.  I re-built Numpy and Scipy with gcc and gfortran, and did some hacking
to ensure that my Weave extension was also being built with gcc.  I get the same error when I try to import the Weave extension.  I do have some new information that might help--I found that I have other library problems in my Scipy build, rather than a Weave-specific issue.  Here is another manifestation of the problem:

>>> from scipy.interpolate import UnivariateSpline
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/cfinch/lib/python2.5/site-packages/scipy/interpolate/__init__.py",
 line 13, in <module>
    from rbf import Rbf
  File "/home/cfinch/lib/python2.5/site-packages/scipy/interpolate/rbf.py", line 47, in <module>
    from scipy import linalg
  File "/home/cfinch/lib/python2.5/site-packages/scipy/linalg/__init__.py", line 13, in <module>
    from iterative import *
  File "/home/cfinch/lib/python2.5/site-packages/scipy/linalg/iterative.py", line 5, in <module>
    from scipy.sparse.linalg import isolve
  File "/home/cfinch/lib/python2.5/site-packages/scipy/sparse/__init__.py", line 6, in <module>
    from csr import *
  File "/home/cfinch/lib/python2.5/site-packages/scipy/sparse/csr.py", line 12, in <module>
    from sparsetools import csr_tocsc, csr_tobsr, csr_count_blocks, \
  File "/home/cfinch/lib/python2.5/site-packages/scipy/sparse/sparsetools/__init__.py", line 4, in <module>
    from csr import *
  File "/home/cfinch/lib/python2.5/site-packages/scipy/sparse/sparsetools/csr.py", line 7, in <module>
    import _csr
ImportError: /home/cfinch/lib/python2.5/site-packages/scipy/sparse/sparsetools/_csr.so: undefined symbol: __gxx_personality_v0

As far as I know, everything Python-related on this machine has now been built with GNU tools, but something is still broken.  One more thing--Python, Numpy, and Scipy are all locally installed in my /home/cfinch directory because the system Python is frozen at 2.4.  Any more ideas?


----- Original Message ----
From: David Cournapeau <david@ar.media.kyoto-u.ac.jp>
To: Craig Finch <cfinch@ieee.org>; SciPy Users List <scipy-user@scipy.org>
Sent: Friday, July 3, 2009 3:19:36 AM
Subject: Re: [SciPy-user] Scipy weave errors: undefined symbols when importing compiled extension

Craig Finch wrote:
> I have two computers that have almost identical Python installations,
> but one of them has problems with inline Weave code.  Here is a simple
> test script that I am using:
> #!/usr/bin/env python
> from scipy import weave
> input_val = 10
> code=r"""return_val = 10*input_val;"""
> print weave.inline(code, ['input_val'], headers=[], compiler='gcc')
> It runs successfully on one computer with the following configuration:
> Python 2.5.2 (r252:60911, Apr 17 2009, 18:42:17) 
> [GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2
> Scipy 0.7.0
> Numpy 1.3.0
> On the other computer, it fails with the following message:
> Traceback (most recent call last):
>   File "test.py", line 12, in <module>
>     print weave.inline(code, ['input_val'], headers=[], compiler='gcc')
>   File "/home/cfinch/lib/python2.5/site-packages/scipy/weave/inline_tools.py", line 335, in inline
>     **kw)
>   File "/home/cfinch/lib/python2.5/site-packages/scipy/weave/inline_tools.py", line 468, in compile_function
>     exec 'import ' + module_name
>   File "<string>", line 1, in <module>
> ImportError: /home/cfinch/.python25_compiled/sc_71b2502f9a0b0ca9f89b0cdc7ad3819e0.so: undefined symbol: _ZNSt8ios_base4InitD1Ev
> I used nm to check, and that symbol is indeed present in the compiled .so file.
> The configuration of this computer is:
> Python 2.5.4 (r254:67916, Apr 22 2009, 15:52:10) 
> [GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
> Scipy 0.7.0
> Numpy 1.3.0
> One
> complication is that the default compiler on this system is icc, and
> numpy distutils doesn't offer a way to force it to use gcc for
> everything.

Mixing C++ compilers is difficult. Icc goes through great length to be
compatible with g++ on Linux, but it is highly version dependent. In
particular, the C++ library often causes problem, which is the case here
it seems. So you're right that you should use gcc to compile the extension.

One thing you could do is to have a script called icc which calls gcc, I
think this works if the script comes first in your path. That's an
horrible hack, though.




More information about the SciPy-user mailing list