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

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,


Dr. Thomas Orgis
Universität Hamburg
RRZ / Basis-Infrastruktur / HPC
Schlüterstr. 70
20146 Hamburg
Tel.: 040/42838 8826
Fax: 040/428 38 6270

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Home | Main Index | Thread Index | Old Index