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