Compiling scipy.sparse.sparsetools extension throws g++ internal error
![](https://secure.gravatar.com/avatar/6e298cec0f82936920673d521345ec0e.jpg?s=120&d=mm&r=g)
Diederik van Liere wrote:
* error: Command "g++ -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3*>>* -Wall -fPIC -I/usr/local/lib/python2.6/site-packages/numpy/core/include*>>* -I/usr/local/include/python2.6 -c scipy/sparse/sparsetools/csr_wrap.cxx -o*>>* build/temp.linux-i686-2.6/scipy/sparse/sparsetools/csr_wrap.o" failed with*>>* exit status 1* What's the version of g++ ? I am using GCC 4.1.2 (32bit)
* and I really don't know how to fix this. I have tried both Numpy 1.3.0 and*>>* the latest Numpy SVN version but to no avail. I hope someone can point me in*>>* the right direction.* Changing numpy version is unlikely to fix anything here, as the error is a crash from the C++ compiler. Okay, good to know.
One solution would be to update gcc (by compiling your own version), or more simply, if you don't need scipy.sparse to disable it in scipy/setup.py by commenting the sparse line. I don't think I will need this, this is for sparse matrix manipulation, right?
I need scipy.linalg although I prefer a complete working version of Scipy because it might the case the sparse module is required by one of other libraries I am suing. But thanks David for giving me some workarounds.
David
![](https://secure.gravatar.com/avatar/0c95cd90aef753bc89f1c48370eeb8b7.jpg?s=120&d=mm&r=g)
Diederik van Liere wrote:
I don't think I will need this, this is for sparse matrix manipulation, right?
Yes.
I need scipy.linalg although I prefer a complete working version of Scipy because it might the case the sparse module is required by one of other libraries I am suing.
Indeed - not building scipy.sparse is clearly a temporary workaround, I would not advise to do this as a long term solution. Another obvious thing to try is building the scipy's trunk, or re-generating the c++ sources from swig. The latter, by generating a different file, may be able to exercise another codepath in g++, and avoid the crash depending on where the crash happens in g++. Ideally, if you could find-out what part of the code causes the crash and report the bug, we may be able to implement a workaround in scipy. cheers, David
participants (2)
-
David Cournapeau
-
Diederik van Liere