tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Deciding on wich variant(s) of OpenBLAS library to install

On 03/13/18 11:02, Dr. Thomas Orgis wrote:
Am Tue, 13 Mar 2018 09:40:03 -0600
schrieb Brook Milligan <>:

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

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 via the alternatives
system, you will have fun linking to a library that depends on, 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/ 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

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,


Sorry for my absence again, still trying to catch up on more immediate priorities.

This has been a very healthy discussion, exposing a lot of potential issues.

I'll just reiterate that I think we need two things for the HPC world:

1. The ability to install multiple BLAS/LAPACK libs simultaneously

2. The ability to override the default for individual dependent packages

As for all the potential problems that have been raised here, I don't think there is a squeaky clean solution that will prevent all issues for either dependent packages or developers outside pkgsrc.

Computational science is inherently messy.  The current state of software deployment is unbelievably messy (caveman installs, numerous deployment tools that don't work together (pip, virtualenv, Yum, etc), containers like Docker being used just to dodge conflicts, etc.  Pkgsrc, even with the problems mentioned here, will make it far less messy.  These problems are minor compared to what people in HPC are used to, so whatever solution we come up with that allows easy BLAS deployment will be enthusiastically welcomed.

Take a look at FreeBSD ports, where Netlib, Atlas, and OpenBLAS are all available.  It's not an ideal solution, and issues do arise, but they're solvable and it's working well in the end.

Home | Main Index | Thread Index | Old Index