Vcpkg: BLAS/LAPACK Binaries

[sarthakpati]

Libraries taking advantage of these would be great!

[traversaro]

I looked into this recently, but I do not plan to work on it anymore in the near future, so I provide by findings if anyone wants to continue working on this.

First of all, the lapack and blas reference implementation are distributed as a unique source archive [1], so I think it make sense to distribute them as a single vcpkg port. The usage of alternative OpenBLAS implementation is typically handled at loading time by tools such as update-alternatives [2] that are currently missing in vcpkg (marginally related issue: https://github.com/Microsoft/vcpkg/issues/164).
As an initial step, I would concentrate only on packaging the blas/lapack port, that I will simply call lapack.

The initial port prototype is available at :
https://github.com/traversaro/vcpkg/tree/add-lapack

It uses the gfortran (provided by mingw-w64 binaries [3]) compiler and the CMAKE_GNUtoMS [4] CMake option to convert the resulting shared libraries in a format compatible with MSVC. The problem is that the resulting dll are dynamically linked against the old msvcrt.dll instead of the proper modern crt.

I quickly checked this issue, and it seems to have been thoroughly investigated by the python community:

• https://mingwpy.github.io/issues.html#choice-of-msvc-runtime
• https://github.com/winpython/winpython/issues/67#issuecomment-95650597
• https://github.com/mingwpy/mingwpy/issues/25#issuecomment-239698119

In particular, I think that the issue can now be partially solved, and the problems still remaining such as file descriptors should not affect a numeric library such as blas/lapack :

• https://github.com/winpython/winpython/issues/67#issuecomment-272655173

Another possible option is to link statically the CRT even on triplet that normally link it dynamically, but at the moment I can't fully evaluate the consequences of such a choice.

[1] : https://github.com/Reference-LAPACK/lapack
[2] : https://wiki.debian.org/DebianScience/LinearAlgebraLibraries
[3] : https://mingw-w64.org/
[4] : https://blog.kitware.com/fortran-for-cc-developers-made-easier-with-cmake/

[traversaro]

BLAS/LAPACK and OpenBLAS are separated projects. To avoid further confusion as in https://github.com/Microsoft/vcpkg/issues/294#issuecomment-281089742 , I suggest to rename this issue to cover just BLAS/LAPACK and eventually open a new one covering just OpenBLAS.

[sarthakpati]

The reason why I had them together was because they are essentially related projects. In any case, I can do what you are suggesting without a problem.

[traversaro]

Thanks @sarthakcbica !

[saedrna]

Because vcpkg is lacking a blas/lapack port, this makes many libraries in scientific computing hard to port to vcpkg.

I am thinking that why not directly use a prebuild binary from openblas sourceforge repo? Because openblas is C, fortran and asm, all of them are ABI safe for different MSVC versions. This is much simpler.

[KindDragon]

This feature can be closed now?

[sarthakpati]

@KindDragon - yes! thanks to @saedrna for his work.