Am Mon, 25 Dec 2023 07:57:15 -0600
schrieb Jason Bacon <jtocino%gmx.com@localhost>:
This is on NetBSD. On Darwin I get the _hmmc import error, like you,
but it doesn't reference blas either:
I'm back to the _hmmc error, but somehow now the linkage in scipy is
correct. A side effect of another change in pkgsrc?
$ ldd /data/pkg/lib/python3.11/site-packages/scipy/sparse/linalg/_dsolve/_superlu.so
linux-vdso.so.1 (0x00007ffe8e9bb000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f824425f000)
libblas.so.3 => /data/pkg/lib/libblas.so.3 (0x00007f8244208000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8243fe0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f82443c8000)
libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007f8243d05000)
libquadmath.so.0 => /lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f8243cbd000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8243c9b000)
With netlib, I can see your failure (missing dtrsm_). The scipy build
apparently does link with `pkg-config --libs cblas`, which resolves to
-lcblas, but no explict -lblas.
Apparently not anymore. I worked on py-pybind11. This is a dependency
of py-scipy. But also reverting my change there, also re-installing the
host system's pybind11-dev for possible interference … that doesn't
influence things.
Something fixed the linkage for me. Can you confirm?
I presume -Wl,--as-needed is in effect, where
Wasn't able to confirm that when looking at a generated build.ninja
from doing the meson call manually (some way to debug the python -m
build path? It hides a lot of the actual build). It looks like normal
libblas linkage now.
While the py-hmmlearn test is still broken … I don't see an issue with
the main pkgsrc packages right now.
Alrighty then,
Thomas