Re: MBF: don't build against libatlas3-base if possible
Hi Ian,
On Wed, Oct 30, 2019 at 01:17:20PM +0000, Ian Jackson wrote:
> Hi. I would like to congratulate you on your work so far. I am no
> expert on this area but from what I read, I want to encourage you :-).
:-)
> I think it's important to give the MBF recipients a clear set of
> instructions on what to change. And to assume that they may not know
> what they are doing :-).
As discussed here, we need to analyze the rdeps of libatlas3-base
case by case because there may be some special situations:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943712
(/me proposed to drop libcblas.so from libatlas3-base)
Following that bug, I've studied two packages and provided patches for them:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943828 (altree)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943827 (meep)
So generally the maintainer should change the B-D
from < libatlas-base-dev > to < libblas-dev >. Sometimes the maintainer
also needs to patch the build system to force it link against -lblas
instead of -lcblsa (see 943828) for example.
> Your email gives clear instructions on what change to the .deb is
> wanted:
> > [...] Ideally any program that needs BLAS/CBLAS ABIs should link
> > against libblas.so.3 instead of libcblas.so.3 (note the char "c" in
> > middle)
>
> But it is not clear to me how this should be achieve in a source
> package which currently build-depends on libatlas3-dev. Can the
> build-dependency simpy be swapped out ? If so, to what ? Or are
> other changes typically needed ?
* A build system that supports many different BLAS implementations should
be able to deal with -- the maintainer just needs to change the B-D.
* When the build system unconditionally links against -lcblas, the
maintainer needs to patch it into -lblas
* If the package is sensitive to BLAS precision, or BLAS speed,
the maintainer may optionaly add this for the binary package:
Recommends: libopenblas-base | libblis2 | libatlas3-base |
libmkl-rt | libblas3 | libblas.so.3
If the reference blas (i.e. libblas3) triggers FTBFS due to
numerical precision problem, building with a high performance BLAS
is fine, but the maintainer should carefully check the resulting
package and avoid unexpected linkage such as -lcblas, -latlas, -lblis,
-lopenblas, -lmkl, etc.
* If the program needs implementation-specific features, no change
would be required. For example, currently Julia needs some specific
features of openblas (openblas_set_num_threads etc) although it
can be disentangled with some effort..
> (Please forgive me for writing this mail without having actually
> looked at any affected source package.)
Nevermind. The MBF title looks short but the underlying problem is
not that simple and straightforward.
> > @Andreas, can we add this point to science-team policy?
>
> I will leave this to Andreas. But if Andreas and the science-team
> agree with you, then this is clearly a candidate for a lintian
> warning. You probably want to file a bug against lintian.
I didn't even think of adding a lintian check for this purpose.
We can add two lintian WARNINGs:
W: linkage-against-specific-blas-lapack-implementation
triggered when detected any specific BLAS/LAPACK implementation
in shlibs:Depends . The package should link against the standard
blas/lapack:
libblas3 | libblas.so.3,
liblapack3 | liblapack.so.3,
In order to enable the update-alternative mechanism.
W: linkage-against-libcblas
triggered when libcblas.so.* has been found in shlibs:Depends.
that indicates the maintainer may have fallen into a trap.
I'll raise a discussion about this on -science and take further
action according to the result.
> Please keep up the good work.
>
> Regards,
> Ian.
>
> --
> Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
>
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
Reply to: