I like using the Debian way and we use a similar thing with the Windows builds for Octave (but just by renaming the OpenBLAS library to be libblas.dll).  But I don't see that we can change the default BLAS library detection in the configure script to always use -lblas because the library might not even be installed on the build system with that name.  Another option is to dynamically load the library at run time, but that brings up a whole other set of issues.

It would be sweet if there were a standard BLAS library function that returned a version string.

In another thread, it sounded like you were saying Homebrew is moving towards OpenBLAS for everything, in which case I would use that and not worry about alternatives.

When I build Octave for other more controlled packaging systems (Docker, Flatpak, and Snap), I usually build with OpenBLAS and don't bake in any choices.

This is one of those things were I almost think that Debian packaging is giving users too much choice.

Here  is with atlas:

$ LD_PRELOAD=/usr/lib64/atlas/libtatlas.so octave -q -f
octave:1> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.7 DYNAMIC_ARCH NO_AFFINITY Sandybridge SINGLE_THREADED)
ATLAS
octave:2>

Dmitri.
--

But even though it's the same code, it's a different aspect of it, so I think @Dmitri should open a separate bug. This bug #57110 is about "Octave's BLAS probe doesn't know about Apple Accelerate". Dmitri's problem is "Octave's BLAS probe detects which BLAS Octave was built against instead of which one it's running against".

Aw, crap. Our whole version detection mechanism here might have a problem: it checks for - (sorry if I got this wrong, I'm no linker expert) - the presence of certain linked BLAS implementation DLLs and distinctive functions within them. As it stands now, this linkage happens at compile time, when Octave is built against a particular BLAS implementation.

Interposing a different BLAS DLL using LD_PRELOAD (or DYLD_INSERT_LIBRARIES on macOS) will change the BLAS implementation that actually gets loaded and called for work, but not undo any previous compile-time linkage, so the probes for other BLAS libraries will still succeed, because some of them check for idiosyncratic aspects of those BLAS implementation libraries, which are not part of the BLAS standard interface, and thus will not be masked by run-time DLL interposition.

So in your case, you interposed the Reference Implementation DLL, masking the build-time-linked OpenBLAS implementation, and that's what was called to do the work. But the OpenBLAS implementation was still linked, including the distinctive implementation-specific `openblas_get_config` function. So when lo-sysinfo's blas_version found openblas_get_config linked, it decided that you're just running OpenBLAS, queried `openblas_get_config` for the OpenBLAS metadata, and didn't know about the RI DLL interposition.

And this is not a cosmetic issue: as you demonstrate, the BLAS you're using significantly affects performance. And I'm working on this problem in the first place because Apple Accelerate/vecLib has some issues that cause Octave test failures or odd numeric results.

It is a bummer that the original designers of the BLAS library didn't include a standard blas_info() function that let you query the implementation metadata. Oh well, live and learn; BLAS was an innovator and library/API design has evolved a lot since then.

I do not know enough about linkers and loaders to know how to do a probe that can detect run-time interposition.

perhaps the following is related (dev version on Fedora):

$ LD_PRELOAD=/usr/lib64/libopenblas.so octave -q -f
octave:1> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.7 DYNAMIC_ARCH NO_AFFINITY Sandybridge SINGLE_THREADED)
octave:2> a=randn(3000);
octave:3> tic; inv(a)*a; toc
Elapsed time is 4.74749 seconds.
octave:4>

$ LD_PRELOAD=/usr/lib64/libopenblasp.so octave -q -f
octave:1> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.7 DYNAMIC_ARCH NO_AFFINITY Sandybridge MAX_THREADS=128)
octave:2> a=randn(3000);
octave:3> tic; inv(a)*a; toc
Elapsed time is 2.03826 seconds.
octave:4>

$ LD_PRELOAD=/usr/lib64/libblas.so.3 octave -q -f
octave:1> version -blas
ans = OpenBLAS (config: OpenBLAS 0.3.7 DYNAMIC_ARCH NO_AFFINITY Sandybridge SINGLE_THREADED)
octave:2> a=randn(3000);
octave:3> tic; inv(a)*a; toc
Elapsed time is 37.4247 seconds.
octave:4>

it misidentifies reference blas as openblas.

Dmitri.
--