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