So thanks again for staying with this. Though it is obvious that the
two viewpoints of upstream developer and package maintainer are not
easily aligned.
My main point about smartness detection certain implementations of
BLAS: I would like projects like NumPy not to waste a single bit on the
question which BLAS family they're using. In the case of Debian with
alternatives switching, they will be always built with Netlib anyway,
and then that is switched around at runtime. So the NumPy build is even
wrong in assuming what it will get at runtime.
Naturally, you want smartness in the build that avoids users asking why
their BLAS stuff is not picked up automatically.
I'd be happy with no detection at all and simple use of provided
BLAS_LIBS and LAPACK_LIBS from the environment (and fallback to -lblas,
-lcblas, -llapack, -llapack3), like it used to be for many projects.
You say you depend on a _project_ that offers certain libraries, not
the individual libraries. In the BLAS/LAPACK case, I'd be happier if
you didn't care which implementation it is. If you do want to use other
parts of MKL, too, it gets messier. You might want to actively avoid
mixing with a differing BLAS in that case, even.
I'll continue to investigate the situation with libblas+libcblas for
Netlib, see
https://github.com/Reference-LAPACK/lapack/issues/968
(hopefully picking up some activity as we pass over into the new year).
I'm not able to convince you to remove all implementation-specific
detection code and instead error out with such if no cblas was found:
Setup error: Did not find working BLAS+CBLAS package. Please point
-Dblas=your-library-here to a pkg-config module that provides
linkage to libraries offering BLAS and CBLAS symbols, as well
as the location of the cblas.h header file.
You know … somewhat like NPY_BLAS_LIBS, NPY_CBLAS_LIBS before;-) But
you did provide your own cblas.h back then. That was suboptimal. Better
would have been to force downstreams to provide a (symlink to) cblas.h
somewhere, IMHO.
Anyhow, somehow we will get along … some (final) remarks inline. Please
note the one about SuperLU: Is the vendoring necessary?
Am Sun, 31 Dec 2023 19:26:33 +0100
schrieb Ralf Gommers :
> So we want "MKL" or "Netlib BLAS", where MKL is not
> only a shared library (or set of them), but for example also the
> corresponding header file (mkl_cblas.h rather than cblas.h). The situation
> you are worrying about is basically that of an unknown package with a set
> of shared libraries and headers that have non-standard names. I'd say that
> that's then simply a non-supported package, until someone comes to report
> the situation and we can add support for it (or file a bug against that
> package and convince the authors not to make such a mess).
I hope to be able to make any such 'nonstandard names' work to be
presented to NumPy and meson as Netlib (compatible), worst case by
providing blas.pc and cblas.pc via build scripts.
> I'll note that the ATL_ symbols prefixes are an internal implementation
> detail; we don't prefix our own symbols when calling BLAS APIs. And there
> is no way Debian lets you install both of Netlib BLAS and ATLAS (it's one
> or the other, through `update-alternatives`), so this can't really go wrong
> in the way you imagine I think.
Nope.
$ ls -l /usr/lib/x86_64-linux-gnu/lib*blas.so.3*
lrwxrwxrwx 1 root root 47 Feb 7 2019
/usr/lib/x86_64-linux-gnu/libblas.so.3 ->
/etc/alternatives/libblas.so.3-x86_64-linux-gnu
lrwxrwxrwx 1 root root 18 Dez 20 2021
/usr/lib/x86_64-linux-gnu/libcblas.so.3 -> libcblas.so.3.10.3
-rw-r--r-- 1 root root 151144 Dez 20 2021
/usr/lib/x86_64-linux-gnu/libcblas.so.3.10.3
lrwxrwxrwx 1 root root 20 Dez 20 2021
/usr/lib/x86_64-linux-gnu/libf77blas.so.3 -> libf77blas.so.3.10.3
-rw-r--r-- 1 root root 146840 Dez 20 2021
/usr/lib/x86_64-linux-gnu/libf77blas.so.3.10.3
only libblas.so is linked to alternatives, as is liblapack.so. Both
libcblas.so and liblapacke.so are not (one is ATLAS, the other is
Netlib!). But we already agreed that this is a mess in Debian;-)
> Note that Debian in addition decided to use custom pkg-config names, so it
> works with `-Dblas=blas-atlas -Dlapack=lapack-atlas`.
Yes, there is only one blas.pc symlink to the chosen alternative and
specific names otherwise. In pkgsrc, it's blas.pc from netlib and
specific names for all other variants. We might switch to a similar
system and rename blas.pc to blas-netlib.pc, so that you are forced to
choose and not have it found automatically.
> If you're renaming build outputs from an
> upstream package from their defaults (e.g. libcblas.so ->
> libcblas-foobar.so), you are breaking things and get to keep the pieces.
> The correct name for Netlib BLAS is `libcblas.so` and `cblas.pc`. So
> provide `cblas.pc`, and you unbreak yourself.
In the case of OpenBLAS, the default library names are (or were at some
point) just unusable in a packaging system, refere
