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>]

Hi all,

I'm trying to update the math/openblas* packages to a new upstream
release that includes some of the old patches. So, patches have to been
re-done. The naming of the shared libraries is … complicated. There is
lots of special naming going on. What my patches, partially upstreamed,
achieve, is a mode where we simply get something like

/pkg/lib/libopenblas_openmp.so.0

and I'm currently working on getting the customary (to me) symlink

/pkg/lib/libopenblas_openmp.so → libopenblas_openmp.so.0

from the upstream Makefiles.

The default upstream build would do this on my random box:

$ ls -l  inst/lib/
libopenblas.a -> libopenblas_haswellp-r0.3.31.a
libopenblas_haswellp-r0.3.31.a
libopenblas_haswellp-r0.3.31.so
libopenblas.so -> libopenblas_haswellp-r0.3.31.so
libopenblas.so.0 -> libopenblas_haswellp-r0.3.31.so

It has a partial encoding of a parallel build being chosen (the 'p' in
there, but not specifying which variant of such) and likes to encode
the host CPU type that the build was optimized for. We choose dynamic
CPU optimization in pkgsrc, but the naming scheme still reflects that
choice. It would be a huge hassle actually supporting differing build
variants, so I reduce all this to one library build per parallelization
(and 64 bit index) variant that has a predictable name, even if the
pkgsrc user disabled the dynamic-arch option.

Anyhow, the library naming as such is patched in upstream and we use
the provided facility. What is still missing is to make
libopenblas.so.0 the primary file and the .so the symlink. The
concerned lines in the Makefile are split between differing OS choices:

#for install shared library
ifneq ($(NO_SHARED),1)
        @echo Copying the shared library to $(DESTDIR)$(OPENBLAS_LIBRARY_DIR)
ifeq ($(OSNAME), $(filter $(OSNAME),Linux SunOS Android Haiku FreeBSD DragonFly))
        @install -m755 $(LIBSONAME) "$(DESTDIR)$(OPENBLAS_LIBRARY_DIR)"
        @cd "$(DESTDIR)$(OPENBLAS_LIBRARY_DIR)" ; \
        $(LNCMD) $(LIBSONAME) $(LIBPREFIX).so ; \
        $(LNCMD) $(LIBSONAME) $(LIBPREFIX).so.$(MAJOR_VERSION)
endif

ifeq ($(OSNAME), $(filter $(OSNAME),OpenBSD NetBSD))
        @cp $(LIBSONAME) "$(DESTDIR)$(OPENBLAS_LIBRARY_DIR)"
        @cd "$(DESTDIR)$(OPENBLAS_LIBRARY_DIR)" ; \
        $(LNCMD) $(LIBSONAME) $(LIBPREFIX).so
endif
ifeq ($(OSNAME), Darwin)
        @-cp $(LIBDYNNAME) "$(DESTDIR)$(OPENBLAS_LIBRARY_DIR)"
        @-install_name_tool -id "$(OPENBLAS_LIBRARY_DIR)/$(LIBPREFIX).$(MAJOR_VERSION).dylib" "$(DESTDIR)$(OPENBLAS_LIBRARY_DIR)/$(LIBDYNNAME)"
        @cd "$(DESTDIR)$(OPENBLAS_LIBRARY_DIR)" ; \
        $(LNCMD) $(LIBDYNNAME) $(LIBPREFIX).dylib ; \
        $(LNCMD) $(LIBDYNNAME) $(LIBPREFIX).$(MAJOR_VERSION).dylib
endif

(dropping lines for WINNT and CYGWIN_NT)


For the packaging in pkgsrc, I set things up so that

LIBSONAME=libopenblas_variant.so.$(MAJOR_VERSION)

(simplified, there are _lots_ of variables and naming schemes involved)

As I see it, I would duplicate the

ln -s $(LIBSONAME) $(LIBPREFIX).so

for both (Linux SunOS Android Haiku FreeBSD DragonFly) and (OpenBSD
NetBSD) when I change the above to cover the case of our library name
choices.

Now to my question: Apart from peculiarities of the OpenBLAS build, is
there a difference in the BSDs compared to Linux when it comes to the
custom of having libfoo.so.0 as the actual library file and the .so
being a symlink to it?

A variant of the question pertains to Darwin, which, looking at PLIST,
is not supported at all by our packages. Someone able to chime in on
how library names _should_ look there? I could prepare things, but
someone needs to test. A usual choice for BLAS there would be the
platform-provided Accelerate framework, though, instead of our openblas
packages.


Alrighty then,

Thomas


PS: I see that libtool use, troublesome and superfluous as it seems at
times, would make this case a lot easiert to me. Wider perspective of
differing OS and all … and no, I do not fancy converting the build to
use libtool and convincing upstream to merge that.

PPS: We (I) dropped static libs from math/lapack and friends as the
upstream build (using cmake) needs extra steps to also get these.
Wondering if we should omit them for openblas, too. Upstream defaults
are not such a strong argument for keeping them in this case, as
everyone has to do some custom stuff to get that packaged/installed,
anyway. Vanilla, it just isn't distributable.

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