Debian Bug report logs - #598638
libatlas3-base: when the LAPACK alternative points to ATLAS, the BLAS alternative should always point to ATLAS

version graph

Package: libatlas3gf-base; Maintainer for libatlas3gf-base is Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>; Source for libatlas3gf-base is src:atlas.

Reported by: Francesco Poli <invernomuto@paranoici.org>

Date: Thu, 30 Sep 2010 17:24:02 UTC

Severity: important

Merged with 576972, 624318, 638236, 676726, 684064

Found in versions atlas/3.8.3-27, atlas/3.8.4-3

Fix blocked by 521813: dpkg: [U-A] please allow hooks after selecting an alternative

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>:
Bug#598638; Package lapack. (Thu, 30 Sep 2010 17:24:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Francesco Poli \(t1000\)" <frx@firenze.linux.it>:
New Bug report received and forwarded. Copy sent to Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>. (Thu, 30 Sep 2010 17:24:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: "Francesco Poli \(t1000\)" <frx@firenze.linux.it>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: lapack: update-alternatives breaks application linking
Date: Thu, 30 Sep 2010 19:19:57 +0200
Package: lapack
Version: 3.2.1-8
Severity: normal

Hi and thanks for maintaining LAPACK in Debian!

I am trying to see how much performance I may gain with ATLAS as a
LAPACK replacement (I will also test the CPU-optimized
libatlas-core2sse3-dev later on).

I am trying to follow instructions included in
http://sylvestre.ledru.info/blog/sylvestre/2010/04/06/update_of_the_linear_algebra_libraries_i

However, it seems that I am doing something wrong, since, after changing
the alternatives, I am no longer able to compile (link, to be precise)
my applications.

Let's describe the problem.
I have just upgraded the following packages

  [INSTALL, DEPENDENCIES] libatlas-dev
  [REMOVE, DEPENDENCIES] libatlas-headers
  [UPGRADE] libatlas-base-dev 3.6.0-24 -> 3.8.3-27
  [UPGRADE] libatlas3gf-base 3.6.0-24 -> 3.8.3-27

since they have recently migrated to testing.
They automatically set the following alternatives:

  # update-alternatives --config libblas.so.3gf 
  There are 2 choices for the alternative libblas.so.3gf (providing /usr/lib/libblas.so.3gf).
  
    Selection    Path                                      Priority   Status
  ------------------------------------------------------------
  * 0            /usr/lib/atlas-base/atlas/libblas.so.3gf   35        auto mode
    1            /usr/lib/atlas-base/atlas/libblas.so.3gf   35        manual mode
    2            /usr/lib/libblas/libblas.so.3gf            10        manual mode
  
  Press enter to keep the current choice[*], or type selection number:
  # update-alternatives --config liblapack.so.3gf
  There are 2 choices for the alternative liblapack.so.3gf (providing /usr/lib/liblapack.so.3gf).
  
    Selection    Path                                        Priority   Status
  ------------------------------------------------------------
  * 0            /usr/lib/atlas-base/atlas/liblapack.so.3gf   35        auto mode
    1            /usr/lib/atlas-base/atlas/liblapack.so.3gf   35        manual mode
    2            /usr/lib/lapack/liblapack.so.3gf             10        manual mode
  
  Press enter to keep the current choice[*], or type selection number:

With these settings, I can compile (and link) programs that use LAPACK:

  $ gfortran -march=native -O3 -mcmodel=large -msse -mfpmath=sse -pipe -o test_0 test.f -llapack
  $ ldd test_0 
        linux-vdso.so.1 =>  (0x00007ffff29ff000)
        liblapack.so.3gf => /usr/lib/liblapack.so.3gf (0x00007ff0eebe5000)
        libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0x00007ff0ee8f9000)
        libm.so.6 => /lib/libm.so.6 (0x00007ff0ee676000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ff0ee460000)
        libc.so.6 => /lib/libc.so.6 (0x00007ff0ee0ff000)
        libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007ff0edbde000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007ff0ed9c2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff0ef811000)

After changing the alternatives to the reference BLAS/LAPACK implementations

  # update-alternatives --config libblas.so.3gf 
  There are 2 choices for the alternative libblas.so.3gf (providing /usr/lib/libblas.so.3gf).
  
    Selection    Path                                      Priority   Status
  ------------------------------------------------------------
  * 0            /usr/lib/atlas-base/atlas/libblas.so.3gf   35        auto mode
    1            /usr/lib/atlas-base/atlas/libblas.so.3gf   35        manual mode
    2            /usr/lib/libblas/libblas.so.3gf            10        manual mode
  
  Press enter to keep the current choice[*], or type selection number: 2
  update-alternatives: using /usr/lib/libblas/libblas.so.3gf to provide /usr/lib/libblas.so.3gf (libblas.so.3gf) in manual mode.
  # update-alternatives --config liblapack.so.3gf
  There are 2 choices for the alternative liblapack.so.3gf (providing /usr/lib/liblapack.so.3gf).
  
    Selection    Path                                        Priority   Status
  ------------------------------------------------------------
  * 0            /usr/lib/atlas-base/atlas/liblapack.so.3gf   35        auto mode
    1            /usr/lib/atlas-base/atlas/liblapack.so.3gf   35        manual mode
    2            /usr/lib/lapack/liblapack.so.3gf             10        manual mode
  
  Press enter to keep the current choice[*], or type selection number: 2
  update-alternatives: using /usr/lib/lapack/liblapack.so.3gf to provide /usr/lib/liblapack.so.3gf (liblapack.so.3gf) in manual mode.

I am no longer able to compile and link the same program:

  $ gfortran -march=native -O3 -mcmodel=large -msse -mfpmath=sse -pipe -o test_1 test.f -llapack
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/liblapack.so: undefined reference to `ATL_chemv'
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/liblapack.so: undefined reference to `ATL_dptsyrk'
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/liblapack.so: undefined reference to `ATL_sspr2'
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/liblapack.so: undefined reference to `ATL_cmoveConj'
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/liblapack.so: undefined reference to `ATL_cgbmv'
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/liblapack.so: undefined reference to `ATL_sspmv'
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/liblapack.so: undefined reference to `ATL_cpttrsm'
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/liblapack.so: undefined reference to `ATL_cscal'
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/liblapack.so: undefined reference to `ATL_ctbmv'
  [...]
  /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/liblapack.so: undefined reference to `ATL_dpttrmm'
  collect2: ld returned 1 exit status

What am I failing to understand?
Is an 'lddconfig' needed, by chance?

I couldn't find documentation about the BLAS/LAPACK alternatives system
implemented in Debian packages.
Where is it explained?

Please help, thanks for your time.


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages liblapack-dev depends on:
ii  libatlas-base-dev [libblas-3g 3.8.3-27   Automatically Tuned Linear Algebra
ii  libblas-dev [libblas-3gf.so]  1.2-7      Basic Linear Algebra Subroutines 3
ii  liblapack3gf                  3.2.1-8    library of linear algebra routines

liblapack-dev recommends no packages.

liblapack-dev suggests no packages.

-- no debconf information




Changed Bug submitter to 'Francesco Poli <invernomuto@paranoici.org>' from '"Francesco Poli \(t1000\)" <frx@firenze.linux.it>' Request was from Francesco Poli <invernomuto@paranoici.org> to control@bugs.debian.org. (Sun, 13 Feb 2011 11:09:41 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>:
Bug#598638; Package lapack. (Thu, 24 Feb 2011 22:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sylvestre Ledru <sylvestre@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>. (Thu, 24 Feb 2011 22:39:03 GMT) Full text and rfc822 format available.

Message #12 received at 598638@bugs.debian.org (full text, mbox):

From: Sylvestre Ledru <sylvestre@debian.org>
To: control@bugs.debian.org, 598638@bugs.debian.org
Subject: Atlas bug
Date: Thu, 24 Feb 2011 23:36:36 +0100
reassign 598638 libatlas3gf-base
thanks

For more information on the bug:
http://lists.debian.org/debian-dpkg/2011/02/msg00069.html

To sum up, this bug comes from the fact that when atlas is used for
lapack, it should set also atlas for blas.

Sylvestre






Bug reassigned from package 'lapack' to 'libatlas3gf-base'. Request was from Sylvestre Ledru <sylvestre@debian.org> to control@bugs.debian.org. (Thu, 24 Feb 2011 22:39:12 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions 3.2.1-8. Request was from Sylvestre Ledru <sylvestre@debian.org> to control@bugs.debian.org. (Thu, 24 Feb 2011 22:39:13 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 598638: 521813 Request was from Sylvestre Ledru <sylvestre@debian.org> to control@bugs.debian.org. (Sun, 06 Mar 2011 11:18:03 GMT) Full text and rfc822 format available.

Forcibly Merged 598638 624318. Request was from Sylvestre Ledru <sylvestre@debian.org> to control@bugs.debian.org. (Wed, 04 May 2011 16:09:14 GMT) Full text and rfc822 format available.

Forcibly Merged 576972 598638 624318. Request was from Sylvestre Ledru <sylvestre@debian.org> to control@bugs.debian.org. (Thu, 09 Jun 2011 15:33:19 GMT) Full text and rfc822 format available.

Forcibly Merged 576972 598638 624318 638236. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Wed, 17 Aug 2011 22:45:08 GMT) Full text and rfc822 format available.

Severity set to 'serious' from 'important' Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Wed, 17 Aug 2011 22:45:11 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>:
Bug#598638; Package libatlas3gf-base. (Mon, 02 Jan 2012 23:15:14 GMT) Full text and rfc822 format available.

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>. (Mon, 02 Jan 2012 23:15:14 GMT) Full text and rfc822 format available.

Message #31 received at 598638@bugs.debian.org (full text, mbox):

From: Francesco Poli <invernomuto@paranoici.org>
To: 598638@bugs.debian.org
Subject: Re: lapack: update-alternatives breaks application linking
Date: Tue, 3 Jan 2012 00:13:13 +0100
[Message part 1 (text/plain, inline)]
On Thu, 30 Sep 2010 19:19:57 +0200 Francesco Poli (t1000) wrote:

[...]
> I am trying to see how much performance I may gain with ATLAS as a
> LAPACK replacement (I will also test the CPU-optimized
> libatlas-core2sse3-dev later on).
> 
> I am trying to follow instructions included in
> http://sylvestre.ledru.info/blog/sylvestre/2010/04/06/update_of_the_linear_algebra_libraries_i
> 
> However, it seems that I am doing something wrong, since, after changing
> the alternatives, I am no longer able to compile (link, to be precise)
> my applications.
[...]

Hello and happy new year!

Any update on this bug?
I took a look at the merged bug reports, but I cannot understand
how and/or when the bug will be fixed...

Is there a workaround?
I mean: is there something that I can do manually in order to make the
whole thing work correctly?

Or should I just go on using the (slow) reference implementation of
LAPACK and wait for this bug to be fixed?


Thanks for your time and for any help you can provide!

-- 
 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
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>:
Bug#598638; Package libatlas3gf-base. (Fri, 13 Jan 2012 20:57:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sylvestre Ledru <sylvestre@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>. (Fri, 13 Jan 2012 20:57:03 GMT) Full text and rfc822 format available.

Message #36 received at 598638@bugs.debian.org (full text, mbox):

From: Sylvestre Ledru <sylvestre@debian.org>
To: Francesco Poli <invernomuto@paranoici.org>, 598638@bugs.debian.org
Subject: Re: Bug#598638: lapack: update-alternatives breaks application linking
Date: Fri, 13 Jan 2012 21:54:39 +0100
Le mardi 03 janvier 2012 à 00:13 +0100, Francesco Poli a écrit :
> On Thu, 30 Sep 2010 19:19:57 +0200 Francesco Poli (t1000) wrote:
> 
> [...]
> > I am trying to see how much performance I may gain with ATLAS as a
> > LAPACK replacement (I will also test the CPU-optimized
> > libatlas-core2sse3-dev later on).
> > 
> > I am trying to follow instructions included in
> > http://sylvestre.ledru.info/blog/sylvestre/2010/04/06/update_of_the_linear_algebra_libraries_i
> > 
> > However, it seems that I am doing something wrong, since, after changing
> > the alternatives, I am no longer able to compile (link, to be precise)
> > my applications.
> [...]
> 
> Hello and happy new year!
> 
> Any update on this bug?
Unfortunately, I don't have any ETA on this.

> 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

> 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)

S






Information forwarded to debian-bugs-dist@lists.debian.org, Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>:
Bug#598638; Package libatlas3gf-base. (Sat, 14 Jan 2012 18:18:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>. (Sat, 14 Jan 2012 18:18:07 GMT) Full text and rfc822 format available.

Message #41 received at 598638@bugs.debian.org (full text, mbox):

From: Francesco Poli <invernomuto@paranoici.org>
To: 598638@bugs.debian.org
Subject: Re: Bug#598638: lapack: update-alternatives breaks application linking
Date: Sat, 14 Jan 2012 19:16:44 +0100
[Message part 1 (text/plain, inline)]
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
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>:
Bug#598638; Package libatlas3gf-base. (Sun, 15 Jan 2012 16:39:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sylvestre Ledru <sylvestre@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>. (Sun, 15 Jan 2012 16:39:07 GMT) Full text and rfc822 format available.

Message #46 received at 598638@bugs.debian.org (full text, mbox):

From: Sylvestre Ledru <sylvestre@debian.org>
To: Francesco Poli <invernomuto@paranoici.org>, 598638@bugs.debian.org
Subject: Re: Bug#598638: lapack: update-alternatives breaks application linking
Date: Sun, 15 Jan 2012 14:31:29 +0100
Hello Francesco,

Le samedi 14 janvier 2012 à 19:16 +0100, Francesco Poli a écrit :
> 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...
Yep, but I am not optimism...
> > 
> > > 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!
Well, if you are looking for performance, continue to use your "pure atlas configuration" (and you could even drop
blas from your 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?
Sure. I am writing this email offline. I cannot point you to my original
email explaining this decision. However, here are some of the reasons:
* atlas is only perfectly optimized when it is built on the target host.
Since every build system in Debian being different, you will get an
atlas optimized for a random system (for example, if you are using
amd64, you would get the version optimized for my laptop).
This applies even with the package libatlas-core2sse3-dev because I
probably have a CPU cache size different from your.
* atlas is optimized for a specific number of threads. This is also
computed at buildtime. For example, if you have 8 cores and the build
machine has only 2, it is likely that your 8 core won't ever be used at
the same time. I could had set a hardcoded number of threads in the
package but it would have been missleading to users and in some cases,
degrading performances
* some build hosts in the debian archs are old and don't have some CPU
extensions (SSE 4 for example). Since I cannot say "
I want atlas to build only on X, Y & Z", we had some random build
failures depending on the host.
* on the overall, it was missleading to users. in the linear algebra
world, users expect to have the best performances at possible. 
With atlas, it is never the case if prebuilt packages are used. The only
right way is to rebuild atlas on your system.
See:
"Building Optimized Atlas Packages on your ARCH"
in /usr/share/doc/libatlas3gf-base/README.Debian.gz

I hope you understand our choose.

Sylvestre






Information forwarded to debian-bugs-dist@lists.debian.org, Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>:
Bug#598638; Package libatlas3gf-base. (Sun, 15 Jan 2012 21:26:56 GMT) Full text and rfc822 format available.

Acknowledgement sent to Francesco Poli <invernomuto@paranoici.org>:
Extra info received and forwarded to list. Copy sent to Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>. (Sun, 15 Jan 2012 21:27:09 GMT) Full text and rfc822 format available.

Message #51 received at 598638@bugs.debian.org (full text, mbox):

From: Francesco Poli <invernomuto@paranoici.org>
To: 598638@bugs.debian.org
Subject: Re: Bug#598638: lapack: update-alternatives breaks application linking
Date: Sun, 15 Jan 2012 22:23:54 +0100
[Message part 1 (text/plain, inline)]
On Sun, 15 Jan 2012 14:31:29 +0100 Sylvestre Ledru wrote:

> Le samedi 14 janvier 2012 à 19:16 +0100, Francesco Poli a écrit :
[...]
> > 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!
> Well, if you are looking for performance, continue to use your "pure atlas configuration" (and you could even drop
> blas from your system)

I am afraid that I won't be able to do otherwise, until this bug gets
fixed...

>  
> 
> > 
> > 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.
[...]
> > Could you please explain?
> Sure. I am writing this email offline. I cannot point you to my original
> email explaining this decision. However, here are some of the reasons:
[...]
> I hope you understand our choose.

Yes, I now understand: as unfortunate as it can be, now I see why a
really optimized ATLAS has to be built on the box where it will be
used...

Thanks a lot for clarifying.

Bye.

-- 
 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
[Message part 2 (application/pgp-signature, inline)]

Severity set to 'important' from 'serious' Request was from Sébastien Villemot <sebastien.villemot@ens.fr> to control@bugs.debian.org. (Mon, 11 Jun 2012 21:48:14 GMT) Full text and rfc822 format available.

Merged 576972 598638 624318 638236 676726 Request was from Sébastien Villemot <sebastien.villemot@ens.fr> to control@bugs.debian.org. (Mon, 11 Jun 2012 21:48:18 GMT) Full text and rfc822 format available.

Severity set to 'serious' from 'important' Request was from Sébastien Villemot <sebastien.villemot@ens.fr> to control@bugs.debian.org. (Tue, 12 Jun 2012 06:27:05 GMT) Full text and rfc822 format available.

Marked as found in versions atlas/3.8.3-27. Request was from Sébastien Villemot <sebastien.villemot@ens.fr> to control@bugs.debian.org. (Wed, 13 Jun 2012 16:33:06 GMT) Full text and rfc822 format available.

Added blocking bug(s) of 598638: 521813 Request was from Sébastien Villemot <sebastien.villemot@ens.fr> to control@bugs.debian.org. (Sat, 16 Jun 2012 07:54:17 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>:
Bug#598638; Package libatlas3gf-base. (Thu, 28 Jun 2012 09:18:51 GMT) Full text and rfc822 format available.

Acknowledgement sent to Sébastien Villemot <sebastien.villemot@ens.fr>:
Extra info received and forwarded to list. Copy sent to Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>. (Thu, 28 Jun 2012 09:18:55 GMT) Full text and rfc822 format available.

Message #66 received at 598638@bugs.debian.org (full text, mbox):

From: Sébastien Villemot <sebastien.villemot@ens.fr>
To: 576972@bugs.debian.org, 598638@bugs.debian.org, 624318@bugs.debian.org, 638236@bugs.debian.org, 676726@bugs.debian.org
Subject: Workaround implemented in atlas 3.8.4-8
Date: Thu, 28 Jun 2012 11:16:36 +0200
[Message part 1 (text/plain, inline)]
Hi,

It seems impossible to elegantly solve this bug without having hooks in
update-alternatives (a wishlist bug is filed for that).

In the meantime, a workaround has been implemented in order to minimize
the incidence of this bug.

Starting from version 3.8.4-8 of Atlas, the Lapack alternative provided
by Atlas has a lower priority than the one provided by Netlib's
reference Lapack. That means that the bug will never hit as long as the
alternatives are left in automatic mode (which is the default).

The downside is that one won't automatically benefit from the
optimizations made by Atlas into Lapack, unless the alternative is
manually modified.

The decision to implement this solution has been made jointly by
Sylvestre Ledru (maintainer), Julien Cristau (Release Team) and myself,
during the Debian Science Sprint kindly sponsored by ESRF, Grenoble,
France.

-- 
Sébastien Villemot
Researcher in Economics & Debian Maintainer
http://www.dynare.org/sebastien
Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594
[Message part 2 (application/pgp-signature, inline)]

Changed Bug title to 'libatlas3-base: when the LAPACK alternative points to ATLAS, the BLAS alternative should always point to ATLAS' from 'lapack: update-alternatives breaks application linking' Request was from Sébastien Villemot <sebastien@debian.org> to control@bugs.debian.org. (Mon, 15 Oct 2012 20:12:07 GMT) Full text and rfc822 format available.

Severity set to 'important' from 'serious' Request was from Michael Gilbert <michael.s.gilbert@gmail.com> to 576972-submit@bugs.debian.org. (Mon, 19 Nov 2012 01:33:03 GMT) Full text and rfc822 format available.

Merged 576972 598638 624318 638236 676726 684064 Request was from Roberto C. Sanchez <roberto@connexer.com> to control@bugs.debian.org. (Mon, 23 Sep 2013 12:12:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>:
Bug#598638; Package libatlas3gf-base. (Tue, 24 Sep 2013 14:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>. (Tue, 24 Sep 2013 14:15:04 GMT) Full text and rfc822 format available.

Message #77 received at 598638@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Sylvestre Ledru <sylvestre@debian.org>
Cc: debian-dpkg@lists.debian.org, 598638@bugs.debian.org
Subject: Re: Question about a alternative impacting on an other
Date: Tue, 24 Sep 2013 16:13:06 +0200
Hi!

[ Leaving most of the original mail intact for context. ]

On Thu, 2011-02-24 at 22:55:44 +0100, Sylvestre Ledru wrote:
> There is what I currently have. 
> I have two important linear algebra librairies which are managed by
> update-alternatives as primary:
> * libblas.so.3gf
> * liblapack.so.3gf
> 
> There are have various implementations. For now, we have a few of them:
> * refblas for libblas.
> * lapack for lapack.
> * atlas which provides both.
> 
> Switching to Atlas will update both blas and lapack alternatives.
> 
> This will work.
> 
> However, if manually, I update liblapack to Atlas:
> update-alternatives --config liblapack.so.3gf
> Obviously, it won't update the libblas.so.3gf.
> 
> In theory, this should not be a problem... However, lapack from Atlas
> uses some internal of libblas.so.
> IE, if the user has libblas.so configured as refblas.so and liblapack.so
> as Atlas. This will break (cf bug #598638).
> 
> Is there a way to have a kind of trigger in update-alternatives for this
> case ?

I don't think this is something that has to be fixed in
update-alternatives. To me this needs to be fixed in atlas itself.

If a library depends on symbols from another library, then it needs to
require so explicitly to the dynamic linker. Requiring the generic
library is not good nor correct enough (even if u-a would enforce some
kind of group links, as hooks is not the solution as they would need to
override any manual setting for example, or automatic priority).

So if liblapack-atlas.so links against libblas-atlas.so, and the
alternatives are set as liblapack.so (atlas) and libblas.so (blas),
an application linking against both generic versions might misbehave
as the linker might pick up symbols from either of the two libblas.so
libraries loaded (atlas, blas). The general solution to that is symbol
versioning. The other solution is to try to move the private symbols
into a common private library.

But here, it appears the solution might be even easier, libatlas3-base
already ships a /usr/lib/libatlas.so.3 library, which seems to contain
(after some random symbol checks) most if not all of the private ATL_
symbols. So it seems the correct fix would be to link both
libblas-atlas.so and liblapack-atlas.so against /usr/lib/libatlas.so.3
(instead of embedding the ATL_ private symbols themselves), this way
liblapack-atlas.so will not be making use of the private ATL_ symbols
from libblas-atlas.so, but directly from libatlas.so. (This should also
reduce the package size!)

Or did I miss something?

Thanks,
Guillem



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sat Apr 19 10:47:13 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.