Building scipy fails because no blas/cblas/lapack libraries are found. I have atlas installed and want scipy to use it. This seems to be a problem of numpy instead, as scipy relies on numpy to detect it. I debugged this to be because `/usr/lib64/python2.7/site-packages/numpy/distutils/system_info.py` does not search for ATLAS in the gentoo style. I attached a patch that succesfully works to detect ATLAS on my gentoo system and also has a working scipy.
Created attachment 347778 [details] patch/workaround
Created attachment 347780 [details] original error message when emerging scipy
Created attachment 347782 [details] emerge --info
Currently installed numpy: [ebuild R ~] dev-python/numpy-1.7.1 USE="lapack -doc {-test}" PYTHON_TARGETS="python2_7 python3_2 -python2_5 -python2_6 -python3_1 (-python3_3)" 0 kB
which atlas are you using? from sci overlay?
Yes, apparently I am using atlas from the science overlay. But I didn't pay good attention here, I had atlas-3.8 installed. The current version in the science overlay is atlas-3.10. Unfortunately, at the moment I am unable to update atlas to the 3.10 version. Now I installed ATLAS from source, and that actuall compiles without problems. It actually also contains files such as libf77blas.a that scipy was searching for an my 3.8 version didn't contain. But I still fail to get it to work with numpy and scipy from gentoo (it is installed in /usr/local/atlas). The failure of the atlas-3.10 version in the science overlay is: /usr/bin/gcc -o ATL_dtrsmRUNU.o -c -DL2SIZE=4194304 -I/var/tmp/portage/sci-libs/atlas-3.10.1-r1/work/ATLAS_shared/include -I/var/tmp/portage/sci-libs/atlas-3.10.1-r1/work/ATLAS//include -I/var/tmp/portage/sci-libs/atlas-3.10.1-r1/work/ATLAS//include/contrib -DAdd_ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_Corei2 -DATL_CPUMHZ=2401 -DATL_AVX -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_USE64BITS -DATL_GAS_x8664 -m64 -DWALL -DATL_FULL_LAPACK -DATL_NCPU=8 -march=nocona -O3 -pipe -fomit-frame-pointer -fPIC -m64 -DDREAL -DUpper_ \ -DNotranspose_ -DUnitDiag_ /var/tmp/portage/sci-libs/atlas-3.10.1-r1/work/ATLAS//src/blas/level3/kernel/ATL_trsmR.c /var/tmp/portage/sci-libs/atlas-3.10.1-r1/work/ATLAS//src/blas/level3/kernel/ATL_trsmKL_rk4.c: In function ‘ATL_rk4’: /var/tmp/portage/sci-libs/atlas-3.10.1-r1/work/ATLAS//src/blas/level3/kernel/ATL_trsmKL_rk4.c:31:4: error: unknown type name ‘__m256d’ /var/tmp/portage/sci-libs/atlas-3.10.1-r1/work/ATLAS//src/blas/level3/kernel/ATL_trsmKL_rk4.c:32:4: error: unknown type name ‘__m256d’ [...]
The proposed patch works for me with atlas 3.10 from the science overlay and numpy 1.7.1.
(In reply to comment #7) > The proposed patch works for me with atlas 3.10 from the science overlay and > numpy 1.7.1. The patch works because you still have leftovers from the old installation. what happens if you do rm /usr/lib{,64}/lib{blas,lapack}.{a,so*} and try again without the patch?
Just hit the same error with numpy-1.8.1. I just don't understand how this can happen. Also I haven't any atlas libary installed (not as such; is it part of BLAS ?).
The error is relatively generic in case of failure to find a suitable blas/lapack, ATLAS or otherwise. So before anything else you should provide the following info eselect blas list eselect cblas list eselect lapack list
# eselect blas list Installed BLAS for library directory lib64 [1] reference * # eselect cblas list Installed CBLAS for library directory lib64 [1] gsl [2] reference * # eselect lapack list Installed LAPACK for library directory lib64 [1] reference *
Can you attach your own build log and site.cfg that should be in ${S}.
Created attachment 382738 [details] numpy build log
Created attachment 382740 [details] numpy site.cfg
I think you have a different problem. blas/lapack is detected at the beginning and something fails later. You should have a build log for python 2.7 and one for 3.3 I would need them as they are mangled in this log and it makes it difficult to stop what happened exactly.
Indeed. I found the issue - numpy doesn't work (anymore?) with -flto. Disabling that flag resolves the issue. Thanks for looking into it.
Interesting. I am not using it myself but I have a hard time thinking numpy does something specific to prevent lto. If it really doesn't work it should be filtered.
dev-python/numpy seems to not handle compiling well using distcc and/or distcc-pump. The following worked for me: # FEATURES="-distcc -distcc-pump" emerge dev-python/nump
Hi, does the fix of Bug 688392 solve this puzzle, too?
Comment #19: I'm currently not using DistCC at this current time.
