Hi Bill,
Once again, please report on bugs.gentoo.org.
> I was trying to use acml to avoid compiling blas-atlas (it takes about 2
> hours and I don't really need it right now. Also numpy and scipy are not
> supposed to require it.
You can disable the USE flag lapack if you don't want to rely on
external cblas or lapack libraries on numpy. For scipy, as far as I
know, you need blas/lapack external libraries. If don't want to wait the
full ATLAS full compilation, you can emerge the
{blas,cblas,lapack}-reference. These are not as speed-optimized as
ATLAS, but a lot faster and more robust to build.
Make sure you have a cblas implementation supporting the eselect format,
as required by dev-python/numpy-1.0.1-r1.
> gcc -shared .libs/libatlas.la-3.o -lpthread
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/32/libgfortran.so -Wl,-soname
> -Wl,libatlas.so.0 -o .libs/libatlas.so.0.0.0
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/32/libgfortran.so: could not read
> symbols: File in wrong format
> collect2: ld returned 1 exit status
> libtool: install: `libatlas.la' is not a valid libtool archive
I can't reproduce your failing blas-atlas (which should be at least
blas-atlas-3.7.11-r1 for numpy-1.0.1-r1). It looks it mixes 32 and 64
profiles.
If it persists, once again, please file a bug regarding blas-atlas on
bugs.gentoo.org.
Sébastien
--
[email protected] mailing list
