Is it possible to unbundle this one?
I think it may be possible by touching scipy/linalg/dsolve/setup.py. If we could avoid the current qhull situation _where_ qhull is built by scipy but in the end it links to the system version it would be nice. Changing superlu_src config.add_extension('_superlu', sources = ['_superlumodule.c', '_superlu_utils.c', '_superluobject.c'], libraries = ['superlu_src'], extra_info = lapack_opt, ) to superlu we bring us to the same case as qhull - buiding but using system library at linking time I believe.
Created attachment 265871 [details, diff] Patch to avoid building superlu and use system version I applied the attached patch and add the proper stuff in the ebuild and it works for me. I also made a patch to avoid building qhull but it should really be separate report.
I additionally delted the SUPERLU dir and corrected the location of headers coming from the system. With this I get: /usr/bin/x86_64-pc-linux-gnu-gfortran -Wall -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -shared build-2.6/temp.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/_iterativemodule.o build-2.6/temp.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/fortranobject.o build-2.6/temp.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/STOPTEST2.o build-2.6/temp.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/getbreak.o build-2.6/temp.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/BiCGREVCOM.o build-2.6/temp.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/BiCGSTABREVCOM.o build-2.6/temp.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/CGREVCOM.o build-2.6/temp.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/CGSREVCOM.o build-2.6/temp.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/GMRESREVCOM.o build-2.6/temp.linux-x86_64-2.6/build-2.6/src.linux-x86_64-2.6/scipy/sparse/linalg/isolve/iterative/QMRREVCOM.o -L/usr/lib64 -L/usr/lib64 -Lbuild-2.6/temp.linux-x86_64-2.6 -llapack -lblas -lcblas -latlas -lcblas -lblas -latlas -lpython2.6 -lgfortran -o build-2.6/lib.linux-x86_64-2.6/scipy/sparse/linalg/isolve/_iterative.so building 'scipy.sparse.linalg.dsolve._superlu' extension compiling C sources C compiler: x86_64-pc-linux-gnu-gcc -pthread -O2 -pipe -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -frecord-gcc-switches -g -Wimplicit-function-declaration -fPIC creating build-2.6/temp.linux-x86_64-2.6/scipy/sparse/linalg/dsolve compile options: '-DATLAS_INFO="\"3.9.23\"" -I/usr/lib64/python2.6/site-packages/numpy/core/include -I/usr/include/python2.6 -c' x86_64-pc-linux-gnu-gcc: scipy/sparse/linalg/dsolve/_superlu_utils.c In file included from scipy/sparse/linalg/dsolve/_superluobject.h:16:0, from scipy/sparse/linalg/dsolve/_superlu_utils.c:8: /usr/include/superlu/slu_scomplex.h:62:8: error: conflicting types for ‘_Py_c_abs’ /usr/include/python2.6/complexobject.h:30:8: note: previous declaration of ‘_Py_c_abs’ was here In file included from scipy/sparse/linalg/dsolve/_superluobject.h:16:0, from scipy/sparse/linalg/dsolve/_superlu_utils.c:8: /usr/include/superlu/slu_scomplex.h:62:8: error: conflicting types for ‘_Py_c_abs’ /usr/include/python2.6/complexobject.h:30:8: note: previous declaration of ‘_Py_c_abs’ was here error: Command "x86_64-pc-linux-gnu-gcc -pthread -O2 -pipe -march=core2 -mcx16 -msahf -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -frecord-gcc-switches -g -Wimplicit-function-declaration -fPIC -DATLAS_INFO="\"3.9.23\"" -I/usr/lib64/python2.6/site-packages/numpy/core/include -I/usr/include/python2.6 -c scipy/sparse/linalg/dsolve/_superlu_utils.c -o build-2.6/temp.linux-x86_64-2.6/scipy/sparse/linalg/dsolve/_superlu_utils.o" failed with exit status 1 * ERROR: sci-libs/scipy-0.9.0 failed (compile phase): * Building failed with CPython 2.6 in distutils_building() function
Created attachment 266807 [details, diff] New patch
I hadn't gone that far. Obviously we have a header problem in superLU. There is a definition duplicating a python one. I notice superLU doesn't depend on python why does it have a python header? Or is it bad luck? I should look at the patch I made for qhull to see if there is a similar problem.
Created attachment 267051 [details, diff] Newest superLU removal patch OK, it seems that the header causing conflict with python is not needed at all for the python extension. So we can just remove it. Give this patch a go.
(In reply to comment #6) Please remove the call to config.add_library() instead of commenting it out.
Created attachment 267135 [details, diff] new patch with Arfrever request There I removed it.
+*scipy-0.9.0-r1 (26 Mar 2011) + + 26 Mar 2011; Justin Lecher <jlec@gentoo.org> scipy-0.8.0.ebuild, + scipy-0.9.0.ebuild, +scipy-0.9.0-r1.ebuild, +files/scipy-0.9.0-qhull.patch, + +files/scipy-0.9.0-superlu.patch: + Unbundled Superlu and Qhull, #357879 +
