Am Tue, 13 Mar 2018 09:40:03 -0600
schrieb Brook Milligan <brook%nmsu.edu@localhost>:
If I as a developer of scientific software have a program that links
both to BLAS and to libfoo, but libfoo also links to BLAS, then there
is a conflict right?
If you link to $BLAS_A and libfoo links to $BLAS_B, you will get
inconsistencies. In practice, one of the BLAS implementations will
‘win’, depending on what was first on the linker command line. Maybe it
is even possible that you get a mix of calls to the one and the other
lib. While this probably will still work, as the BLAS routines do the
same computations in the end, the performance of your program might be
unpredictable.
This is the situation you now have on any Linux distro that features
multiple BLAS libs. Even on Debian, which has the most advanced way of
dealing with this by switching libblas.so.3 via the alternatives
system, you will have fun linking to a library that depends on
libopenblasp.so.x, for example. Suddenly you have multithreaded BLAS in
your program although you think you linked to a serial one.
I will be forced to use the pkgsrc-blessed BLAS.
If you want to be sure that your build is consistent, then yes.
If so, how can I develop anything on top of a pkgsrc like this?
Carefully;-) But indeed, this opens the question of how to easily get
the correct BLAS lib name to use to be consistent with pkgsrc. Just
installing a $PKGSRC_PREFIX/lib/libblas.so would not do it for the case
of having built pkgsrc with the Intel compiler and MKL, for example.
Installing a $PKGSRC_PREFIX/lib/pkgconfig/blas.pc that always points to
the default pkgsrc BLAS (installed when that one is installed … with
dynamic PLIST entry) would do the trick, though.
At that point, pkgsrc becomes useful only for applications compiled
within pkgsrc (or being satisfied with whatever BLAS has been
selected) and it becomes useless as a tool for developers to deploy
an array of needed libraries for their development work.
I am not sure at what point we crossed the line here. What is the bad
thing?
a) shipping multiple BLAS
b) selecting only one to link to inside pkgsrc
c) that you are now aware of many choices for BLAS
Perhaps I am misunderstanding things, but this would be a massive
step backwards.
A step backwards from _where_? Currently, pkgsrc only has slow
math/blas from Netlib. Heck, you even have possibly several packges
using internal copies of Netlib going unnoticed. Are you suggesting
that we go back to my initial (one of them) proposal to install one and
only one BLAS in one pkgsrc tree? Then we have your voice in direct
opposition to Jason's, on grounds of supporting scientific software (on
top, or inside pkgsrc).
Alrighty then,
Thomas