> Hi,
>
> I think I got the last bit of hardcoding of atlas in the building of sage.
> You can now use any (c)blas you want - including ATLAS if you wish.
> I know it will be a relief to some of you.
>
There are a few points that should be made clear I think.
If you want everything to work properly you need to compile everything
with one set up of cblas/blas/lapack otherwise some inconsistency will
appear. Also switching implementation on the fly may not necessarilly
work.
As an example I just switched from ATLAS to cblas=gsl, blas=goto
lapack=reference. However I had compiled everything against ATLAS.
Lets have a look at a library from numpy:
ldd /usr/lib/python2.6/site-packages/numpy/linalg/lapack_lite.so
linux-gate.so.1 => (0xb781c000)
liblapack.so.0 => /usr/lib/liblapack.so.0 (0xb727b000)
libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xb7121000)
libc.so.6 => /lib/libc.so.6 (0xb6fb3000)
libblas.so.0 => /usr/lib/blas/atlas/libblas.so.0 (0xb6f93000)
libgfortran.so.3 => /usr/lib/gcc/i686-pc-linux-
gnu/4.4.4/libgfortran.so.3 (0xb6ecb000)
libm.so.6 => /lib/libm.so.6 (0xb6ea4000)
libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.4.4/libgcc_s.so.1
(0xb6e86000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb6e6c000)
libdl.so.2 => /lib/libdl.so.2 (0xb6e68000)
libutil.so.1 => /lib/libutil.so.1 (0xb6e63000)
/lib/ld-linux.so.2 (0xb781d000)
libatlas.so.0 => /usr/lib/libatlas.so.0 (0xb67a4000)
As you can see atlas path seems to be hardcoded for blas. If I compile
something against this numpy library now that I have switched problems
may occur.
scipy is another case that may misbehave, we even have an atlas_version.so
library produced.
ldd /usr/lib/python2.6/site-packages/scipy/linalg/atlas_version.so
linux-gate.so.1 => (0xb7726000)
libatlas.so.0 => /usr/lib/libatlas.so.0 (0xb7039000)
libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xb6edf000)
libc.so.6 => /lib/libc.so.6 (0xb6d71000)
libm.so.6 => /lib/libm.so.6 (0xb6d4a000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb6d30000)
libdl.so.2 => /lib/libdl.so.2 (0xb6d2b000)
libutil.so.1 => /lib/libutil.so.1 (0xb6d27000)
/lib/ld-linux.so.2 (0xb7727000)
And scipy rely on numpy too.
Anyway a recompile later with cblas from gsl:
ldd /usr/lib/python2.6/site-packages/scipy/linalg/cblas.so
linux-gate.so.1 => (0xb784f000)
libgslcblas.so.0 => /usr/lib/libgslcblas.so.0 (0xb77de000)
libpython2.6.so.1.0 => /usr/lib/libpython2.6.so.1.0 (0xb7684000)
libc.so.6 => /lib/libc.so.6 (0xb7516000)
libm.so.6 => /lib/libm.so.6 (0xb74ef000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb74d5000)
libdl.so.2 => /lib/libdl.so.2 (0xb74d0000)
libutil.so.1 => /lib/libutil.so.1 (0xb74cc000)
/lib/ld-linux.so.2 (0xb7850000)
Now we link to libgslcblas directly. Stand alone it may work (or not since I
didn't recompile numpy). Switching cblas won't affect that linking either.
But changing cblas with eselect and compiling against scipy without
recompiling it first may land you into trouble.
Francois
