Debian Bug report logs - #732064
lapack depends on specific blas implementation

Display info messages

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

From: Andrey Gursky <andrey.gursky@e-mail.ua>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: lapack depends on specific blas implementation

Date: Fri, 13 Dec 2013 14:34:30 +0100

Source: lapack
Version: 3.5.0-2
Severity: important

Dear maintainers,

after updating lapack from 3.4.2 to 3.5.0, provided instead of atlas
openblas is selected, running a program, using lapack results in
following error:

symbol lookup error: /usr/lib/liblapack.so.3: undefined symbol: ATL_dGetNB

A new lapack build seems to be sticked to the atlas blas-library?


Thanks,
Andrey

Message #10 received at 732064@bugs.debian.org (full text, mbox, reply):

From: Sébastien Villemot <sebastien@debian.org>

To: Andrey Gursky <andrey.gursky@e-mail.ua>, 732064@bugs.debian.org

Subject: Re: Bug#732064: lapack depends on specific blas implementation

Date: Fri, 13 Dec 2013 15:28:09 +0100

[Message part 1 (text/plain, inline)]

Le vendredi 13 décembre 2013 à 14:34 +0100, Andrey Gursky a écrit :

> after updating lapack from 3.4.2 to 3.5.0, provided instead of atlas
> openblas is selected, running a program, using lapack results in
> following error:
> 
> symbol lookup error: /usr/lib/liblapack.so.3: undefined symbol: ATL_dGetNB

Your problem looks very much like #576972 and its many duplicates. I.e.
it looks like you are using ATLAS for the LAPACK alternative and
reference BLAS or OpenBLAS for the BLAS alternative.

To confirm this, can you please give the output of the following two
commands:

 update-alternatives --display libblas.so.3
 update-alternatives --display liblapack.so.3

Thanks,

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 732064@bugs.debian.org (full text, mbox, reply):

From: Andrey Gursky <andrey.gursky@e-mail.ua>

To: Sébastien Villemot <sebastien@debian.org>

Cc: 732064@bugs.debian.org

Subject: Re: Bug#732064: lapack depends on specific blas implementation

Date: Tue, 17 Dec 2013 16:47:45 +0100

2013/12/13, Sébastien Villemot <sebastien@debian.org>:
> Le vendredi 13 décembre 2013 à 14:34 +0100, Andrey Gursky a écrit :
>
>> after updating lapack from 3.4.2 to 3.5.0, provided instead of atlas
>> openblas is selected, running a program, using lapack results in
>> following error:
>>
>> symbol lookup error: /usr/lib/liblapack.so.3: undefined symbol:
>> ATL_dGetNB
>
> Your problem looks very much like #576972 and its many duplicates. I.e.
> it looks like you are using ATLAS for the LAPACK alternative and
> reference BLAS or OpenBLAS for the BLAS alternative.
>
> To confirm this, can you please give the output of the following two
> commands:
>
>  update-alternatives --display libblas.so.3
>  update-alternatives --display liblapack.so.3
>

Sebastien, thanks for pointing this out. I've also got caught in the
same trap. But this would mean a trade-off, since openblas's version
of lapack is just striped away for now. Should I open a new bug for
openblas or could it be, that optimizations of openblas's lapack are
not significant enough?

I'm wondering, whether lapack interface could be remaining general
modified in a way, atlas and openblas could use it without changing.
Or the things are more complicated?

Thanks,
Andrey

Message #22 received at 732064@bugs.debian.org (full text, mbox, reply):

From: Sébastien Villemot <sebastien@debian.org>

To: Andrey Gursky <andrey.gursky@e-mail.ua>

Cc: 732064@bugs.debian.org

Subject: Re: Bug#732064: lapack depends on specific blas implementation

Date: Thu, 19 Dec 2013 21:11:26 +0100

[Message part 1 (text/plain, inline)]

Le mardi 17 décembre 2013 à 16:47 +0100, Andrey Gursky a écrit :

> Sebastien, thanks for pointing this out. I've also got caught in the
> same trap. But this would mean a trade-off, since openblas's version
> of lapack is just striped away for now. Should I open a new bug for
> openblas or could it be, that optimizations of openblas's lapack are
> not significant enough?

My understanding is that OpenBLAS does not provide a specialized version
of LAPACK. It just gives the possibility of bundling LAPACK within the
libopenblas.a, which is uninteresting for us. But I have not
investigated this too much, so if OpenBLAS provides a customized LAPACK
as ATLAS does, then please open a wishlist bug against openblas.

> I'm wondering, whether lapack interface could be remaining general
> modified in a way, atlas and openblas could use it without changing.
> Or the things are more complicated?

When you use the general LAPACK in Debian, you still benefit from ATLAS
and OpenBLAS optimizations everytime LAPACK calls a BLAS function. Does
this answer your question?

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

[signature.asc (application/pgp-signature, inline)]

Message #27 received at 732064@bugs.debian.org (full text, mbox, reply):

From: Andrey Gursky <andrey.gursky@e-mail.ua>

To: Sébastien Villemot <sebastien@debian.org>

Cc: 732064@bugs.debian.org

Subject: Re: Bug#732064: lapack depends on specific blas implementation

Date: Fri, 20 Dec 2013 17:30:22 +0100

2013/12/19, Sébastien Villemot <sebastien@debian.org>:
> Le mardi 17 décembre 2013 à 16:47 +0100, Andrey Gursky a écrit :
>
>> Sebastien, thanks for pointing this out. I've also got caught in the
>> same trap. But this would mean a trade-off, since openblas's version
>> of lapack is just striped away for now. Should I open a new bug for
>> openblas or could it be, that optimizations of openblas's lapack are
>> not significant enough?
>
> My understanding is that OpenBLAS does not provide a specialized version
> of LAPACK. It just gives the possibility of bundling LAPACK within the
> libopenblas.a, which is uninteresting for us. But I have not
> investigated this too much, so if OpenBLAS provides a customized LAPACK
> as ATLAS does, then please open a wishlist bug against openblas.

I just was confused by the thread [1], where an opinion(?) was expressed:
"Now, because the both ATLAS and OpenBLAS versions of LAPACK have some
functions overridden with more efficient versions..."

Now comparing OpenBLAS.git and lapack-3.5.0 yields:
...
Only in OpenBLAS.git/lapack: getf2
Only in OpenBLAS.git/lapack: getrf
Only in OpenBLAS.git/lapack: getri
Only in OpenBLAS.git/lapack: getrs
...
Only in OpenBLAS.git/lapack: laswp
Only in OpenBLAS.git/lapack: lauu2
Only in OpenBLAS.git/lapack: lauum
...
Only in OpenBLAS.git/lapack: potf2
Only in OpenBLAS.git/lapack: potrf
Only in OpenBLAS.git/lapack: trti2
Only in OpenBLAS.git/lapack: trtri

>> I'm wondering, whether lapack interface could be remaining general
>> modified in a way, atlas and openblas could use it without changing.
>> Or the things are more complicated?
>
> When you use the general LAPACK in Debian, you still benefit from ATLAS
> and OpenBLAS optimizations everytime LAPACK calls a BLAS function. Does
> this answer your question?

Yes, I was surprised, that besides a BLAS optimization an optimization
of LAPACK is also needed. Considering at least a statement from ATLAS
FAQ [2]:
"The provided LAPACK routines utilize a recursive algorithm that
should yield reliably better results than the more common
staticly-blocked algorithms."
and it seems the ATLAS LAPACK is not a patched general netlib LAPACK at all.

Anyway, I believe, this bug report belongs to be merged with the one
you've mentioned (#576972).

[1] https://fedorahosted.org/fpc/ticket/352
[2] http://math-atlas.sourceforge.net/faq.html#optcomp

Message #44 received at 732064@bugs.debian.org (full text, mbox, reply):

From: Guillem Jover <guillem@debian.org>

To: Sébastien Villemot <sebastien@debian.org>, 732064@bugs.debian.org

Cc: Andrey Gursky <andrey.gursky@e-mail.ua>

Subject: Re: Bug#732064: lapack depends on specific blas implementation

Date: Tue, 15 Jul 2014 18:55:04 +0200

Hi!

On Fri, 2013-12-13 at 15:28:09 +0100, Sébastien Villemot wrote:
> Le vendredi 13 décembre 2013 à 14:34 +0100, Andrey Gursky a écrit :
> > after updating lapack from 3.4.2 to 3.5.0, provided instead of atlas
> > openblas is selected, running a program, using lapack results in
> > following error:
> > 
> > symbol lookup error: /usr/lib/liblapack.so.3: undefined symbol: ATL_dGetNB
> 
> Your problem looks very much like #576972 and its many duplicates. I.e.
> it looks like you are using ATLAS for the LAPACK alternative and
> reference BLAS or OpenBLAS for the BLAS alternative.

As I mentioned some time ago, it seems to me this is entirely fixable
within BLAS and LAPACK, and IMO the problem is in how those shared
libraries are currently built. Please take a look at the mail I sent,
and let me know if there's any hole in the analysis:

  <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598638#77>

Thanks,
Guillem

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

From: Sébastien Villemot <sebastien@debian.org>

To: Guillem Jover <guillem@debian.org>

Cc: 732064@bugs.debian.org, Andrey Gursky <andrey.gursky@e-mail.ua>

Subject: Re: Bug#732064: lapack depends on specific blas implementation

Date: Wed, 16 Jul 2014 20:33:11 +0200

[Message part 1 (text/plain, inline)]

Le mardi 15 juillet 2014 à 18:55 +0200, Guillem Jover a écrit :

> On Fri, 2013-12-13 at 15:28:09 +0100, Sébastien Villemot wrote:
> > Le vendredi 13 décembre 2013 à 14:34 +0100, Andrey Gursky a écrit :
> > > after updating lapack from 3.4.2 to 3.5.0, provided instead of atlas
> > > openblas is selected, running a program, using lapack results in
> > > following error:
> > > 
> > > symbol lookup error: /usr/lib/liblapack.so.3: undefined symbol: ATL_dGetNB
> > 
> > Your problem looks very much like #576972 and its many duplicates. I.e.
> > it looks like you are using ATLAS for the LAPACK alternative and
> > reference BLAS or OpenBLAS for the BLAS alternative.
> 
> As I mentioned some time ago, it seems to me this is entirely fixable
> within BLAS and LAPACK, and IMO the problem is in how those shared
> libraries are currently built. Please take a look at the mail I sent,
> and let me know if there's any hole in the analysis:
> 
>   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598638#77>

Thanks Guillem, I had overlooked your message above. Indeed I think that
the solution that you propose is the right one. I have implemented it
locally and it seems to work. I'll upload it soon if everything goes
well.

-- 
 .''`.    Sébastien Villemot
: :' :    Debian Developer
`. `'     http://www.dynare.org/sebastien
  `-      GPG Key: 4096R/381A7594

[signature.asc (application/pgp-signature, inline)]

Message #54 received at 576972-close@bugs.debian.org (full text, mbox, reply):

From: Sébastien Villemot <sebastien@debian.org>

To: 576972-close@bugs.debian.org

Subject: Bug#576972: fixed in atlas 3.10.2-2

Date: Tue, 05 Aug 2014 19:33:49 +0000

Source: atlas
Source-Version: 3.10.2-2

We believe that the bug you reported is fixed in the latest version of
atlas, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 576972@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Sébastien Villemot <sebastien@debian.org> (supplier of updated atlas package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Tue, 05 Aug 2014 18:13:33 +0200
Source: atlas
Binary: libatlas3-base libatlas3gf-base libatlas-base-dev libatlas-dev libatlas-test libatlas-doc
Architecture: source all amd64
Version: 3.10.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Team <debian-science-maintainers@lists.alioth.debian.org>
Changed-By: Sébastien Villemot <sebastien@debian.org>
Description:
 libatlas-base-dev - Automatically Tuned Linear Algebra Software, generic static
 libatlas-dev - Automatically Tuned Linear Algebra Software, C header files
 libatlas-doc - Automatically Tuned Linear Algebra Software, documentation
 libatlas-test - Automatically Tuned Linear Algebra Software, test programs
 libatlas3-base - Automatically Tuned Linear Algebra Software, generic shared
 libatlas3gf-base - Transitional package to libatlas3-base
Closes: 576972
Changes:
 atlas (3.10.2-2) unstable; urgency=medium
 .
   * shared_libraries.diff: no longer include ATLAS-specific symbols in
     libblas.so and liblapack.so. Rather dynamically link those libraries with
     libatlas.so. This makes it possible to use liblapack.so from ATLAS with a
     libblas.so coming from somewhere else. Thanks to Guillem Jover for
     suggesting this solution. (Closes: #576972)
   * Revert back to a higher priority in the LAPACK alternatives.
     The priority had been lowered in 3.8.4-8 in order to minimize the incidence
     of #576972, so this is no longer needed.
Checksums-Sha1:
 44e2068df19fafa6f600effd088206cdf8b7fd07 2422 atlas_3.10.2-2.dsc
 fbe8e103c791b00efa9c915122f17210a0d1b8f9 109640 atlas_3.10.2-2.debian.tar.xz
 303b22405fe6328de117e94cf4d3126b097ea320 51138 libatlas3gf-base_3.10.2-2_all.deb
 3a9bf98a2ca69d4aeb16891e29e611c3085af3aa 68086 libatlas-dev_3.10.2-2_all.deb
 d7ba71298f634ec4583e82a04eab22fd3a9e466b 1148810 libatlas-doc_3.10.2-2_all.deb
 38b61bb4dada606d9e3613e626142ed070fe7af1 2490864 libatlas3-base_3.10.2-2_amd64.deb
 4c985c6108bc25d5b77427f9814be4132b319212 3097166 libatlas-base-dev_3.10.2-2_amd64.deb
 64e618bdb5074933e8270ca9c427ffee0f02ff78 1777854 libatlas-test_3.10.2-2_amd64.deb
Checksums-Sha256:
 6b851bcac272f873daef03e815cfe8d6b649b0775be4cde7a46b8634816da22e 2422 atlas_3.10.2-2.dsc
 cdec7950fa6926e56194bc5b72de2bc3f17bc3238cd48c55546ab3dfcac5c716 109640 atlas_3.10.2-2.debian.tar.xz
 b9003002edcb93baa695825f860f18dc9d3c18d643fb09f626d0388ecc7647c9 51138 libatlas3gf-base_3.10.2-2_all.deb
 27cceee5ad4ec3eb0a16cb5f7c15b703195d86331fbb3e804a6c90e8a89b8a13 68086 libatlas-dev_3.10.2-2_all.deb
 8ff1869e1c1a2897814cb1e03e5e982091d79f3596fb294a32c3953e059d05a4 1148810 libatlas-doc_3.10.2-2_all.deb
 b32522cc5536f0bab8fac3aa35d0b1393ab8da20c8dba1f66f8a20bd609a55cc 2490864 libatlas3-base_3.10.2-2_amd64.deb
 547d6ab4d2630c2a5a0ef74f53e5c3e1cb25c162e859f0f555e834e9d690eb73 3097166 libatlas-base-dev_3.10.2-2_amd64.deb
 5c1b76d5f3215121c55a2a933dd708e8d97c3b131f44e9346da06cf46890b0bb 1777854 libatlas-test_3.10.2-2_amd64.deb
Files:
 23fe49f33f8fa1daf6598fc9d89f422e 51138 oldlibs optional libatlas3gf-base_3.10.2-2_all.deb
 d83589fa0f703e1ebcfce996b021c977 68086 libdevel optional libatlas-dev_3.10.2-2_all.deb
 a629460e5b4b4b27753bb4dddae55a1d 1148810 doc optional libatlas-doc_3.10.2-2_all.deb
 da3a534794e01dd82d21af7edb0e8c1e 2490864 libs optional libatlas3-base_3.10.2-2_amd64.deb
 069f6ad5eaffc56ff1d6cad2ed1a8a5c 3097166 libdevel optional libatlas-base-dev_3.10.2-2_amd64.deb
 137fb8a7a55c3ac910d284f482c75ee0 1777854 devel extra libatlas-test_3.10.2-2_amd64.deb
 dbfc23de4b16969f03e367189e0b9fb4 2422 devel optional atlas_3.10.2-2.dsc
 68adc578ab4886f36e9dfb3eea8bb249 109640 devel optional atlas_3.10.2-2.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIbBAEBCAAGBQJT4Q2fAAoJECzs6TUOzr5KxxsP+IDsTX/DPLHJIsJ4yBRKr3Fx
xdKdjaZAV1y0x9fvoN0/fM4Oyk1YruoQQCUZg4xEame+lgXCQJo0Vq1qnUFq2Ait
o+Tr3A4rPkizY7LrOOljvENV04PRgoZl3jaZqVfBuPpo8q7XpU3b2pLajZRi4fFC
+2vLM9MscQrFnaL1p7Iy/SSWgKPv4DrrUfXv9txEwpgHhTevKTO/XsUhfR5dCpS7
rfMftz2964mdkCpxyFQwgU+XzZ4kbnGTfJrY6lk+OSfWjTWwlhi8/BApu+kvjXru
4q+8bMpFVL6EykkMZfChV3QWF0BpqPUycz83ogGf1t7ToWmqgfpbGozzA9WbnIsu
OQVkhqiGo3gRoUod8z5Tv2ep7qOQ/6R/gZgiTS13CpCzIQjtB0LFYFJpv5zCLQax
sRifFIfixmB0fdJiG/amnBO9Yb5D35Di2FUi7gkA9FRiAwdRbwOFn21B3pH78DID
Xh4JH7tNCF2kvDD4IQWl2/eMbjUXelJ7zSrVzMyqinmM4Djs8xs/f6mtN1FFj6YJ
Aa+YvOaRgYqlwLcJINmvM1MDD7bi1mA9PxlSB9/zV2JbW/BZKrlq7IgMyW6WkLdM
PacD8xK++2CrwhIzeaR/iZRWgFP7ZFEb1On0iHSSOw2oaEFvl3uD2ptAxTITRNtQ
5dlyPGm7IzP2kX7ExM8=
=Da6q
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.