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