[gentoo-science] [sage-on-gentoo]sage is now cleanly independent of ATLAS

[gentoo-science] [sage-on-gentoo]sage is now cleanly independent of ATLAS

[François Bissey]

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 is still a mystery about linbox detecting clapack, providing its own 
headers for it and linking with it. 
The mystery is the lack of lapack in the resulting library:

Francois

Re: [gentoo-science] [sage-on-gentoo]sage is now cleanly independent of ATLAS

[François Bissey]

> 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