Re: Difference on shared lib installation on NetBSD vs. Linux and others (trying to update openblas packages)

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

Am Sun, 22 Feb 2026 16:44:09 +0000
schrieb Taylor R Campbell <riastradh%NetBSD.org@localhost>:

> No.  How it works on essentially all ELF platforms:

Thanks for the clarification. So this is a quirk in the OpenBLAS
Makefiles that they special-case *BSD. It looks like the
libopenblas.so.0 symlink is _not_ created there. Maybe there is
corresponding logic elsewhere that creates a .so.0 file/link. It could
be that this is an accident. Interestingly, the soname of the default

libopenblas_haswellp-r0.3.31.so

is libopenblas.so.0. Furthermore, there is a CMake build, too, which
defaults to building

libopenblas.so.0.3

which then has .so.0 and .so symlinks. I doubt that there is proper
library versioning going on.

In fact, the $(LNCMD) in the Makefile snippet is turned into a no-op
for our use case (using a switcht to get a fixed library name), with
upstream assuming that we don't even want the symlinks, then. I could
run with that and create the symlinks afterwards, in the pkgsrc
Makefile. Not sure what is the better aproach here … and if upstream
would be willing to accept more patches to this library naming mess.

> If there is some CPU-specific optimization available, ideally we
> would:
[…]
> 2. ship _all_ the optimized libraries libopenblas_haswell.so.N,
>    libopenblas_skylake.so.N, libopenblas_zenryzenepyc.so.N, &c.,
>    unconditionally for amd64 builds;

The default for the pkgsrc package is to build all CPU optimizations
into the library with run-time dispatch based on host CPU. I think this
is reasonable for packaging. The user may override that via options.mk
to only build to their specific host CPU.

> In any case, if you want `-lopenblas' to work, then:

I'll keep the .so.0 and .so symlink, then.

I wonder if I should try to fix things for Darwin, too. Actually, I may
have forgotten. Will PLIST with

lib/lib${OPENBLAS_VARIANT}.so
lib/lib${OPENBLAS_VARIANT}.so.0

be automatically translated to .dylib on Darwin? I guess that would be
one of the benefits of .la files in there, that they are universal?


Regards,

Thomas

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