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

"Dr. Thomas Orgis" <[email protected]>
Newsgroups gmane.os.netbsd.devel.packages
Organization Universität Hamburg
Message-ID <20260222222812.7fe013d7@plasteblaster>
Am Sun, 22 Feb 2026 16:44:09 +0000
schrieb Taylor R Campbell <[email protected]>:

> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.