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
pgpRloMHGDy04.pgp
Description: PGP signature
