Bug#598638: lapack: update-alternatives breaks application linking

[Francesco Poli]

On Fri, 13 Jan 2012 21:54:39 +0100 Sylvestre Ledru wrote:

> Le mardi 03 janvier 2012 à 00:13 +0100, Francesco Poli a écrit :
[...]
> > Hello and happy new year!
> > 
> > Any update on this bug?
> Unfortunately, I don't have any ETA on this.

OK, let's hope it may be fixed soon...

> 
> > I took a look at the merged bug reports, but I cannot understand
> > how and/or when the bug will be fixed...
> See this bug on the actual solution:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=521813

Unfortunately, I am afraid I cannot help much here.   :-(

> 
> > Is there a workaround?
> > I mean: is there something that I can do manually in order to make the
> > whole thing work correctly?
> Of course!
> 
> When you run atlas, make sure that both blas and lapack ATLAS
> implementation are used in the configure (both runtime & -dev packages)

I am not sure I understand what you mean...

The default configuration has the alternatives set so that both blas and
lapack ATLAS implementations are used.
This setup *works for me*: I can compile, link, and run applications
using lapack, with no issues at all (see the original bug report).

What I initially tried to do (again, see the original bug report) was
exactly the opposite of what you seem to suggest: I wanted to change
the alternatives so that both blas and lapack *reference*
implementations are used.
The reason is that I wanted to see how much *worse* those reference
implementations would perform with respect to the ATLAS implementations.
I tried to follow the instructions explained in
http://sylvestre.ledru.info/blog/sylvestre/2010/04/06/update_of_the_linear_algebra_libraries_i
but the result was that I could no longer compile and link the simple
test program I was using as a minimal benchmark...
I see that the same instructions are included
in /usr/share/doc/libatlas3gf-base/README.Debian.gz
Well, they do *not* seem to work for me.

Could you please clarify what you suggest, and explicitly spell out the
commands I should issue to switch to the reference implementations, and
the commands to switch back to the ATLAS implementations?
I would like to minimize the risk of breaking my production system!


BTW, according to my original plan, I wanted to also test
libatlas-core2sse3-dev, but the optimized packages have been dropped,
as stated in the README.Debian file.
Well, the explanation for this decision is not really clear to me: why
is it suggesting that *each* interested user rebuilds *each* new
version of the package on his/her own box, when buildds could do this
job *once* for all the users (for each version)?
This is Debian, after all, not Gentoo!
I acknowledge that Debian packages are usually not optimized for
specific CPUs, and generally only one port per architecture is present
in the archive. But ATLAS is a bit special in this respect: it is "born
to be optimized" (yeah, it sounds like a parody of a famous song!). 

Could you please explain?

Thanks for your time and patience!


-- 
 http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
 New GnuPG key, see the transition document!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20120114/82ecdd22/attachment.pgp>