[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: BLAS/LAPACK implementations



On Mon, 2010-02-08 at 15:18 +0100, Axel Freyn wrote:
> Hello Adam,
> On Mon, Feb 08, 2010 at 08:39:50AM -0500, Adam C Powell IV wrote:
> > Hello,
> > 
> > Some time ago, the netlib and ATLAS implementations of BLAS and LAPACK
> > were ABI-compatible, and used alternatives symlinks to access their
> > different libraries with the same ABI.
> > 
> > I don't know when it happened, but at some point they diverged, and now
> > the netlib packages have libblas-3gf.so and liblapackgf-3.so, and ATLAS
> > has libblas-3.so and liblapack-3.so.
> If I remember correctly, that renaming was due to the compiler-update
> from g77 to gfortran (which are NOT ABI-compatible!): Packages whose
> names end with "gf" are supposed to be compiled and linked with
> gfortran, while the older ones use g77. As this was a release goal for
> Lenny, it should be finished by now - and also atlas should use now
> gfortran, thus being again ABI-compatible with BLAS.

That much I got...

> > I know that ATLAS has its own API as well, but it was nice back in the
> > day to be able to build to the netlib API, and then swap them back at
> > forth at runtime using update-alternatives.
> > 
> > Are they no longer ABI-compatible?  Is it possible to get back to the
> > old state of things?
> Did you try to install the package "libatlas3gf-base"? Last time I checked
> it on my machine (squeeze), it was no problem to switch between netlib
> and atlas withour recompiling: just changing LD_LIBRARY_PATH to link to
> the netlib-versions did the trick. And I have 
> /usr/lib/atlas/libblas.so.3gf which belongs to the package
> "libatlas3gf-base".

I have that package installed.

I think I understand.  So whereas there used to be an /etc/alternatives
mechanism for selecting between netlib and ATLAS libraries, now one must
use LD_LIBRARY_PATH.  Makes sense.

So the alternatives symlinks I mentioned above are now useless?  Or do
they need updating so they're at least consistent?  Perhaps they should
both link from libblas.so.3gf?

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: