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

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 :

vs2015 python 3.5 winpython/winpython#67 (comment)

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/

BLAS/LAPACK Binaries #23

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions