Re: py-scipy build failure on NetBSD 9.3

["Dr. Thomas Orgis" <thomas.orgis%uni-hamburg.de@localhost>]

Am Mon, 29 Apr 2024 17:34:39 -0400
schrieb "David H. Gutteridge" <david%gutteridge.ca@localhost>:

> On Mon, 29 Apr 2024 at 08:46:14 -0500, Jason Bacon wrote:
> > Anyone else running into this?

> > Run-time dependency pybind11 found: YES 2.12.0
> > Run-time dependency blas found: YES 3.12.0
> > Run-time dependency cblas found: NO (tried pkgconfig and cmake)

I need to study what changed. It used to be the case that the build
detects libcblas being present if netlib BLAS is chosen. That is why
this worked:

BLAS_C_INTERFACE=	yes
WHEEL_ARGS+=		-Csetup-args=-Dblas=${BLAS_PC}
WHEEL_ARGS+=		-Csetup-args=-Dlapack=${LAPACK_PC}

The build just guessed that it will need libcblas.so if BLAS is
libblas.so.

There is (was) only a knob to tell it about BLAS, not CBLAS … and for
all implementations except the reference, both interfaces are contained
in the same library. I tried to argue for a more generic build
configuration interface, allowing various naming schemes for the
libraries, but didn't convince much.

Seems like the reference BLAS case (about which upstreams do not care
much) has been broken again with the recent upgrade. I'll try to look
into some knob to turn. AFAIR, I even used to have

WHEEL_ARGS+=		-Csetup-args=-Dblas=${CBLAS_PC}

at some point. This also does not look clean, but it would pull in both
libcblas and libblas … except … I faintly remember subtle linking
issues we had.

Anyhow, I'd expect this to be an issue on any platform that relies on
netlib BLAS?! Is this only happening on NetBSD?


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg