[vcpkg baseline] Re-fix lapack-reference to find blas on windows-static #19608

JackBoosY · 2021-08-17T07:25:56Z

The origin issue is:

openblas comes with lapack, lapack comes with blas, cblas, lapacke.
vcpkg only wants to build one lib of those in the ports, so lapack-reference should only build lapack, openblas should only build openblas. Due to the gfortran constrains lapack needs to build its internal blas in x64-windows-static.

The problem: FindBlas.cmake picks up a spurious openblas installation of vcpkg in one port since it was installed while another port was looking for it but that port did not declare the dependency on openblas -> error in colmap since openblas is not restored by CI.

This PR will

Add port blas-reference and disable lapack-reference to build internal blas.
Add FindBLAS.cmake provided by cmake and modify some codes to adapt to Windows or x64 build.
Add vcpkg-cmake-wrapper to blas-reference to avoid finding openblas.

Related: #19628

Thanks @Neumann-A!

JackBoosY · 2021-08-17T07:26:08Z

cc @Neumann-A @cenit

github-actions

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

After committing all other changes, the version database must be updated

git add -u && git commit
git checkout d679a1e0befa9c9e36fcda169c94f6daba2224b7 -- versions
./vcpkg x-add-version --all

Diff

diff --git a/versions/b-/blas.json b/versions/b-/blas.json
index 7fb0192..6d991bf 100644
--- a/versions/b-/blas.json
+++ b/versions/b-/blas.json
@@ -1,5 +1,10 @@
 {
   "versions": [
+    {
+      "git-tree": "2c785ddee8825820b71ad4f8f3be588c8158906e",
+      "version-semver": "3.10.0",
+      "port-version": 0
+    },
     {
       "git-tree": "2877c1693c63195d4edacfb42156c9d8874ad046",
       "version-string": "1",
diff --git a/versions/baseline.json b/versions/baseline.json
index 2855173..0ac5e18 100644
--- a/versions/baseline.json
+++ b/versions/baseline.json
@@ -421,7 +421,7 @@
       "port-version": 0
     },
     "blas": {
-      "baseline": "1",
+      "baseline": "3.10.0",
       "port-version": 0
     },
     "blaze": {

github-actions

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

After committing all other changes, the version database must be updated

git add -u && git commit
git checkout d679a1e0befa9c9e36fcda169c94f6daba2224b7 -- versions
./vcpkg x-add-version --all

Diff

diff --git a/versions/b-/blas.json b/versions/b-/blas.json
index 7fb0192..801ba36 100644
--- a/versions/b-/blas.json
+++ b/versions/b-/blas.json
@@ -1,5 +1,10 @@
 {
   "versions": [
+    {
+      "git-tree": "8876f20d092c072b4f7a80db2e5a877ab000dda9",
+      "version-semver": "3.10.0",
+      "port-version": 0
+    },
     {
       "git-tree": "2877c1693c63195d4edacfb42156c9d8874ad046",
       "version-string": "1",
diff --git a/versions/baseline.json b/versions/baseline.json
index 2855173..0ac5e18 100644
--- a/versions/baseline.json
+++ b/versions/baseline.json
@@ -421,7 +421,7 @@
       "port-version": 0
     },
     "blas": {
-      "baseline": "1",
+      "baseline": "3.10.0",
       "port-version": 0
     },
     "blaze": {

Neumann-A · 2021-08-17T07:31:39Z

?!?!? who removed the blas metaport?

also what you are adding here is blas-reference. just like lapack-reference.

github-actions

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

After committing all other changes, the version database must be updated

git add -u && git commit
git checkout d679a1e0befa9c9e36fcda169c94f6daba2224b7 -- versions
./vcpkg x-add-version --all

Diff

diff --git a/versions/b-/blas.json b/versions/b-/blas.json
index 7fb0192..d1c61b5 100644
--- a/versions/b-/blas.json
+++ b/versions/b-/blas.json
@@ -1,5 +1,10 @@
 {
   "versions": [
+    {
+      "git-tree": "75b6ee2b0d4236f48b310cc69de037bfb9b34cc6",
+      "version-semver": "3.10.0",
+      "port-version": 0
+    },
     {
       "git-tree": "2877c1693c63195d4edacfb42156c9d8874ad046",
       "version-string": "1",
diff --git a/versions/baseline.json b/versions/baseline.json
index 2855173..0ac5e18 100644
--- a/versions/baseline.json
+++ b/versions/baseline.json
@@ -421,7 +421,7 @@
       "port-version": 0
     },
     "blas": {
-      "baseline": "1",
+      "baseline": "3.10.0",
       "port-version": 0
     },
     "blaze": {

github-actions

This is a new experimental fast check for PR issues. Please let us know if this bot is helpful!

After committing all other changes, the version database must be updated

git add -u && git commit
git checkout d679a1e0befa9c9e36fcda169c94f6daba2224b7 -- versions
./vcpkg x-add-version --all

Diff

diff --git a/versions/b-/blas.json b/versions/b-/blas.json
index 7fb0192..a283f48 100644
--- a/versions/b-/blas.json
+++ b/versions/b-/blas.json
@@ -1,5 +1,10 @@
 {
   "versions": [
+    {
+      "git-tree": "a297c47bd805c00b2308f027d288f3d9544aae33",
+      "version-semver": "3.10.0",
+      "port-version": 0
+    },
     {
       "git-tree": "2877c1693c63195d4edacfb42156c9d8874ad046",
       "version-string": "1",
diff --git a/versions/baseline.json b/versions/baseline.json
index 2855173..0ac5e18 100644
--- a/versions/baseline.json
+++ b/versions/baseline.json
@@ -421,7 +421,7 @@
       "port-version": 0
     },
     "blas": {
-      "baseline": "1",
+      "baseline": "3.10.0",
       "port-version": 0
     },
     "blaze": {

JackBoosY · 2021-08-17T07:39:15Z

@Neumann-A I want to clarify the relationship between blas and lapack's reference and non-reference, can you elaborate on it?

Neumann-A · 2021-08-17T07:41:46Z

@JackBoosY: Please keep blas a metaport. What you are adding here is blas-reference. There a many ways vcpkg could provide blas/lapack but the current idea is to have the blas port just check that blas can be found and depend on vcpkg defaults blas implementation (openblas). Using an overlay this could be changed to e.g. using mkl instead.

JackBoosY · 2021-08-17T07:57:56Z

@Neumann-A What about the dependencies between them? This PR start with a ci regression when building colmap:x64-windows-static:

ninja: error: 'D:/installed/x64-windows-static/debug/lib/openblas.lib', needed by 'src/exe/colmap.exe', missing and no known rule to make it

Colmap's dependency chain:
colmap -> ceres/suitesparse -> lapack -> lapack-reference -> blas -> openblas
Their messy dependencies have now affected other ports such as colmap.

The fact is: lapack-reference generates blas and conflicts with openblas.

Neumann-A · 2021-08-17T08:07:03Z

@JackBoosY That is just someone linking openblas but not declaring the dependency correctly:

neumann@heineken MINGW64 /e/qt6 (update_qt6_6.2)
$ ./vcpkg.exe depend-info colmap:x64-windows-static | findstr openblas

neumann@heineken MINGW64 /e/qt6 (update_qt6_6.2)

vs

neumann@heineken MINGW64 /e/qt6 (update_qt6_6.2)
$ ./vcpkg.exe depend-info colmap:x64-windows | findstr openblas
openblas:
blas: openblas

so some target has a dependency on openblas but does not have it in its build-depends which is why ci is not restoring openblas. Find the target which links openblas and make the dependency on blas explicit.

Neumann-A · 2021-08-17T08:09:49Z

furthermore this is related to #15571. vcpkg needs to force the internally used blas and lapack version to avoid finding spurious other stuff.

JackBoosY · 2021-08-17T08:11:31Z

@Neumann-A But the libblas generated by lapack-reference contains the same symbols as the openblas generated by openblas.

And according to the upstream issue OpenMathLib/OpenBLAS#203, the blas used in lapack-reference is not openblas.

cenit · 2021-08-17T08:22:54Z

And according to the upstream issue OpenMathLib/OpenBLAS#203, the blas used in lapack-reference is not openblas.

i think that issue talks about the opposite: openblas contains lapack-reference

the two algebra libraries are really tangled together, the best option is disabling lapack in openblas and blas in lapack-reference, and then explicitly depend on both.

as @Neumann-A is saying, colmap error should be just a matter of fact of a port depending (wrongly) on openblas(!static)

JackBoosY · 2021-08-17T08:23:59Z

After comparing the blas source code in lapack-reference with the source code in blas, I found that they are almost the same (except some comments).
Although the feature noblas of lapack-reference depends on openblas, it still uses the internal blas code to generate libblas, and creates a link with the pkgconfig of openblas In the lib folder, this obviously violates the dependency.

Neumann-A · 2021-08-17T08:28:20Z

The problem is lapack-reference cannot link against openblas from vcpkg if VCPKG_CRT_LINKAGE is static since gfortran cannot simply link against the MSVC CRT in this case. As such lapack-reference has to use its internal blas implementation in this case. As already said switching to ifort solves this problem.

Neumann-A · 2021-08-17T08:31:26Z

After comparing the blas source code in lapack-reference with the source code in blas, I found that they are almost the same (except some comments).

Yeah because it is the reference implementation in both cases ;) lapack-reference could probably do a FETCH_CONTENT of the blas stuff

JackBoosY · 2021-08-17T08:32:42Z

@JackBoosY That is just someone linking openblas but not declaring the dependency correctly:
neumann@heineken MINGW64 /e/qt6 (update_qt6_6.2)
$ ./vcpkg.exe depend-info colmap:x64-windows-static | findstr openblas

neumann@heineken MINGW64 /e/qt6 (update_qt6_6.2)
vs
neumann@heineken MINGW64 /e/qt6 (update_qt6_6.2)
$ ./vcpkg.exe depend-info colmap:x64-windows | findstr openblas
openblas:
blas: openblas
so some target has a dependency on openblas but does not have it in its build-depends which is why ci is not restoring openblas. Find the target which links openblas and make the dependency on blas explicit.

That because:

vcpkg/ports/lapack-reference/CONTROL

Lines 15 to 17 in d679a1e

    
           Feature: blas-select
 
           Build-Depends: lapack-reference[core, noblas](!windows|!static)
 
           Description: Use external optimized BLAS

According to my poor experience with blas and lapack, I can't distinguish the relationship between them at all.

Neumann-A · 2021-08-17T08:41:22Z

@JackBoosY: Just think of the CMakeLists.txt of both ports as superbuilds.

openblas comes with lapack
lapack comes with blas, cblas, lapacke

vcpkg only wants to build one lib of those in the ports:
so lapack-reference should only build lapack
openblas should only build openblas

due to the gfortran constrains lapack needs to build its internal blas in x64-windows-static.
The problem: FindBlas.cmake picks up a spurious openblas installation of vcpkg in one port since it was installed while another port was looking for it but that port did not declare the dependency on openblas -> error in colmap since openblas is not restored by CI.

That is why vcpkg needs to force the correct blas library to be used via a wrapper.

JackBoosY · 2021-08-17T09:30:41Z

The problem: FindBlas.cmake picks up a spurious openblas installation of vcpkg in one port since it was installed while another port was looking for it but that port did not declare the dependency on openblas -> error in colmap since openblas is not restored by CI.

But why create a link to the pkgconfig file of openblas? lapack-reference also provides blas.pc.
If it uses internal blas, it should not depend on blas in CONTROL.

Neumann-A · 2021-08-17T10:01:26Z

If it uses internal blas, it should not depend on blas in CONTROL.

it does. since lapack is providing blas. in this case.

But why create a link to the pkgconfig file of openblas?

that is probably a bug.

JackBoosY · 2021-08-18T06:36:35Z

If it uses internal blas, it should not depend on blas in CONTROL.

it does. since lapack is providing blas. in this case.

But why create a link to the pkgconfig file of openblas?

that is probably a bug.

This will be fixed in #19628.

JackBoosY · 2021-09-01T06:47:51Z

This baseline regression blocked 5-6 PRs, @ras0219-msft please make some suggestions.

ras0219-msft

@Neumann-A Thanks for the summary (#19608 (comment))

openblas comes with lapack
lapack comes with blas, cblas, lapacke

vcpkg only wants to build one lib of those in the ports:
so lapack-reference should only build lapack
openblas should only build openblas

To put more words on the subject for other readers, here are our objectives:

If a consumer depends on blas, then find_package(BLAS) will resolve (+pkgconfig)
If a consumer depends on lapack, then find_package(LAPACK) will resolve (+pkgconfig)
There will be only one provider of BLAS or LAPACK symbols in a given build tree
(ideally) Official vcpkg triplets will provide a consistent default choice for lapack backend. I'm not yet certain whether the gfortran issue makes this intractable for static-crt triplets.
Consumers have a choice of backends to provide blas and lapack by replacing blas or lapack and their choice should be respected by the tree (including builds failing if appropriate)

Then, we need to determine what the space of backends looks like. Given @Neumann-A's summary, it looks to me like there are several possible configurations:

lapack-reference[noblas] & openblas[nolapack]
openblas[blas,lapack]
mpl & lapack-reference[noblas] (?)
lapack-reference[noblas] & blas-reference[noblas]
Built in MacOS option for BLAS?

Open questions:

How does cblas fit into this? Can we have it be implied by blas or is it useful for it to be a unique metaport?
What restrictions do the major packages have w.r.t. incompatibilities (such as the gfortran issue)?
What other major packages are relevant to this space?
How do we test this? This is another "forks the entire graph" situation like openssl/libressl/boringssl. Perhaps we need to just pick the default subset that we will test the world against and relegate other configurations to community registries that can provide more domain-specific testing?

ras0219-msft · 2021-09-02T22:53:44Z

ports/blas-reference/FindBLAS.cmake

@@ -0,0 +1,1191 @@
+


We should not be checking in a thousand lines of CMake upstream sources. Either:

(bad option) This should be downloaded from GitHub (https://raw.githubusercontent.com/Kitware/CMake/v3.21.1/Modules/FindBLAS.cmake)

(good option) The point of providing this overlay is to force the vcpkg BLAS version. Therefore, there is no need for hundreds of these lines -- we just need to define the outputs listed in https://cmake.org/cmake/help/latest/module/FindBLAS.html to point at the copy of BLAS we just built.

we just need to define the outputs listed in

Please also add the check that the libraries are actual usable.

The reason why I manually put FindBLAS.cmake into the port directory is that the version provided by cmake is not suitable for the port blas-reference.
In windows, if BUILD_X64 is turned on, blas-reference will generate libblas64.lib, and when searching, only blas will be found.
And FindBLAS.cmake whcih provided by cmake doesn't provide any marco to fix that.

If the FindBLAS from CMake is not usable and we need to replace it in this case, that's fine. However, we do not need a thousand lines of CMake to do that -- a much smaller file will do fine.

cenit · 2021-09-03T04:57:44Z

about the configurations: we have also clapack already in tree, it was our default lapack port before lapack-reference was accepted

also, macOS Accelerate Framework contains BLAS but also LAPACK.

Final note: all implementations must have compatible ABI and they have, at least as far as i know (not headers, it is common to just call libraries knowing their interface)

JackBoosY · 2021-09-03T09:17:12Z

ports/blas-reference/vcpkg-cmake-wrapper.cmake

+set(BLA_VENDOR "Generic")
+_find_package(${ARGS})


Suggested change

set(BLA_VENDOR "Generic")

_find_package(${ARGS})

if (WIN32)

set(CMAKE_FIND_LIBRARY_PREFIXES_BAK ${CMAKE_FIND_LIBRARY_PREFIXES})

set(CMAKE_FIND_LIBRARY_PREFIXES lib)

endif()

set(BLA_VENDOR "Generic")

_find_package(${ARGS})

if (WIN32)

set(CMAKE_FIND_LIBRARY_PREFIXES ${CMAKE_FIND_LIBRARY_PREFIXES})

endif()

In FindBLAS.cmake line 1156:

# Generic BLAS library? if(BLA_VENDOR STREQUAL "Generic" OR BLA_VENDOR STREQUAL "NVHPC" OR BLA_VENDOR STREQUAL "All") if(NOT BLAS_LIBRARIES) check_blas_libraries( BLAS_LIBRARIES BLAS sgemm "" "blas" "" "" "" ) endif() endif()

line 275:

function(CHECK_BLAS_LIBRARIES LIBRARIES _prefix _name _flags _list _deps _addlibdir _subdirs) ... find_library(${_prefix}_${_lib_var}_LIBRARY NAMES ${_library} NAMES_PER_DIR PATHS ${_extaddlibdir} PATH_SUFFIXES ${_subdirs} )

Unless we forced the 64bit openblas-reference library name to blas.lib or libblas.lib, we can't search it using FindBLAS.cmake provided by cmake.

Neumann-A · 2021-09-03T10:29:48Z

I'm not yet certain whether the gfortran issue makes this intractable for static-crt triplets.

the problem lies mainly with the Fortran library. Because that is linked with the mingw stuff and requires ld as a linker due to internal symbol stuff. If We could link against a naively build windows Fortran library the problem goes away (#19413 does this by switching to ifort). One problem still is that the compiler Fortran libraries have not set the /APPCONTAINER bit so strictly speaking Fortran on UWP is currently not supported.
The only solution I see for the UWP problem in the future is to switch to the Fortran library provided by LLVM via Flang which will be build by vcpkg itself and will set the bit correclty.

There will be only one provider of BLAS or LAPACK symbols in a given build tree

that would be the ideal situation but it is already broken due to intel-mkl also providing blas/lapack symbols. It is more important to force the lookup of find_package(BLAS), find_package(LAPACK) to the selection of the metaport dependency blas/lapack. Here XOR features would be helpful to cover the cases without forcing users to use an overlay (Just like BLA_VENDOR in CMake).

How does cblas fit into this?

cblas is just a C wrapper to the legacy blas library. As such it can be installed using any blas implementation. It will wrap the fortran symbols using a cblas_ prefix

What restrictions do the major packages have w.r.t. incompatibilities (such as the gfortran issue)?

as said the incompatibility is mainly due to the linkage problems with libgfortran.lib in static builds. If we ca get a native windows variant there is only the issue with UWP an the missing appcontainer bit. There is no ABI implication.

What other major packages are relevant to this space?

Just look into CMakes FindBLAS.cmake/FindLAPACK.cmake. We currently have intel-mkl, openblas, blas-reference, lapack-reference, macOS Accelerate Framework, clapack (outdated IMHO). There are probably also variants with openMP/MPI enabled?

How do we test this? This is another "forks the entire graph" situation like openssl/libressl/boringssl. Perhaps we need to just pick the default subset that we will test the world against and relegate other configurations to community registries that can provide more domain-specific testing?

Give a reasonable default; Let the rest be handled by the community. There could be some basic testing of a minimal port tree which uses LAPACK/BLAS to check if it at least works. But that is always the case for features in ports. vcpkg never checks all features in CI.

ras0219-msft · 2021-09-03T21:28:32Z

If We could link against a naively build windows Fortran library the problem goes away

Hmm, maybe splitting the .lib back into objects and then using msvc to re-create the static lib would help? ~~I'll try this.~~

Edit: I'm not sure how to precisely set up the conditions to test this.

... intel-mkl also providing blas/lapack ...

Isn't this handled by simply overlaying both lapack and blas to point at mkl then?

It is more important to force the lookup of find_package(BLAS), find_package(LAPACK) to the selection of the metaport dependency blas/lapack.

Agreed, this seems critical. If we think "cross" configurations like lapack-reference LAPACK on top of intel-mkl BLAS are also important, then this may require features to request "find_package(X) support" -- the exclusivity would be across packages and not within a package. It still is suboptimal, but I think it should be functional enough to work for now. Specifically, intel-mkl[lapack] would provide share/lapack/vcpkg-cmake-wrapper.cmake to force mkl as your lapack provider, but it wouldn't provide that by default. To make the global selection, you'd overlay a lapack -> intel-mkl[lapack] and blas -> intel-mkl[core]. Same story for the various other "interesting" configurations.

XOR features would be helpful to cover the cases without forcing users to use an overlay

Agreed, though I think that will still require the basic structure I've indicated above.

As such it can be installed using any blas implementation

But can we assume every blas implementation will install it? Do we need to have an explicit port that just creates the wrapper?

cenit · 2021-09-06T16:34:02Z

ports/blas-reference/usage

@@ -0,0 +1,5 @@
+Use this package via the module FindBLAS that comes with CMake. To use in your CMakeLists.txt:


this is not true because we are checking-in our own modified version

JackBoosY · 2021-09-18T07:46:24Z

The solution accepted, but the FindBLAS.cmake needs to be minimized.
Does FindBLAS.cmake only provided for port blas-reference? We have other port cblas, openblas.
We now have two approaches:

Provide Findblas.cmake to blas-reference and reduce its content.
Provide Findblas.cmake to all blas-like ports and keep all the content.

JackBoosY · 2021-11-19T09:23:27Z

In favor of #21479.

[blas] Re-add port blas

11d5f6d

JackBoosY added category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist info:internal This PR or Issue was filed by the vcpkg team. labels Aug 17, 2021

JackBoosY assigned PhoebeHui Aug 17, 2021

github-actions bot requested changes Aug 17, 2021

View reviewed changes

Add patch

5594726

github-actions bot requested changes Aug 17, 2021

View reviewed changes

Add cmake usage

1e19f46

github-actions bot requested changes Aug 17, 2021

View reviewed changes

Use modern cmake related functions, set default features

6db9e11

github-actions bot requested changes Aug 17, 2021

View reviewed changes

Add dependency vcpkg-gfortran on Windows

735f4c5

c72578 mentioned this pull request Aug 17, 2021

[lcms] Update to 2.12 #19551

Merged

JackBoosY added category:port-bug The issue is with a library, which is something the port should already support and removed category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist labels Sep 1, 2021

PhoebeHui added the category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist label Sep 1, 2021

JackBoosY removed the category:port-feature The issue is with a library, which is requesting new capabilities that didn’t exist label Sep 1, 2021

ras0219-msft requested changes Sep 2, 2021

View reviewed changes

JackBoosY commented Sep 3, 2021

View reviewed changes

PhoebeHui approved these changes Sep 6, 2021

View reviewed changes

cenit reviewed Sep 6, 2021

View reviewed changes

PhoebeHui added the requires:author-response label Sep 7, 2021

JackBoosY mentioned this pull request Sep 7, 2021

[lapack-reference] build failure #19982

Closed

BillyONeal mentioned this pull request Sep 11, 2021

re-enable qt5-activeqt #20083

Merged

BillyONeal added 2 commits September 13, 2021 14:33

Merge remote-tracking branch 'origin/master' into HEAD

4774545

Remove colmap from ci.baseline.txt.

38697c7

github-actions bot approved these changes Sep 13, 2021

View reviewed changes

JackBoosY mentioned this pull request Oct 25, 2021

[lapack-reference] Does not contain instructions for using cblas #20952

Closed

JackBoosY linked an issue Oct 25, 2021 that may be closed by this pull request

[lapack-reference] Does not contain instructions for using cblas #20952

Closed

JackBoosY removed the requires:author-response label Oct 25, 2021

This was referenced Nov 10, 2021

[lapack-reference] Fix issue when using an external Fortran compiler #21254

Closed

[LAPACK] build failure #20323

Open

ras0219-msft mentioned this pull request Nov 17, 2021

[blas][lapack] Reorganize lapack/blas metaport system #21479

Closed

LilyWangLL mentioned this pull request Nov 19, 2021

Fail to install lapack:x64-windows-static #21512

Closed

JackBoosY removed the requires:vcpkg-team-review This PR or issue requires someone on the vcpkg team to take a further look. label Nov 19, 2021

JackBoosY closed this Nov 19, 2021

JackBoosY deleted the dev/jack/Re-add-blas branch May 26, 2022 07:44

-set(BLA_VENDOR "Generic")
-_find_package(${ARGS})
+if (WIN32)
+    set(CMAKE_FIND_LIBRARY_PREFIXES_BAK ${CMAKE_FIND_LIBRARY_PREFIXES})
+    set(CMAKE_FIND_LIBRARY_PREFIXES lib)
+endif()
+set(BLA_VENDOR "Generic")
+_find_package(${ARGS})
+if (WIN32)
+    set(CMAKE_FIND_LIBRARY_PREFIXES ${CMAKE_FIND_LIBRARY_PREFIXES})
+endif()

		@@ -0,0 +1,5 @@
		Use this package via the module FindBLAS that comes with CMake. To use in your CMakeLists.txt:

[vcpkg baseline] Re-fix lapack-reference to find blas on windows-static #19608

[vcpkg baseline] Re-fix lapack-reference to find blas on windows-static #19608

Conversation

JackBoosY commented Aug 17, 2021 • edited by PhoebeHui Loading

JackBoosY commented Aug 17, 2021

github-actions bot left a comment

Choose a reason for hiding this comment

github-actions bot left a comment

Choose a reason for hiding this comment

Neumann-A commented Aug 17, 2021

github-actions bot left a comment

Choose a reason for hiding this comment

github-actions bot left a comment

Choose a reason for hiding this comment

JackBoosY commented Aug 17, 2021

Neumann-A commented Aug 17, 2021

JackBoosY commented Aug 17, 2021 • edited Loading

Neumann-A commented Aug 17, 2021

Neumann-A commented Aug 17, 2021

JackBoosY commented Aug 17, 2021 • edited Loading

cenit commented Aug 17, 2021

JackBoosY commented Aug 17, 2021 • edited Loading

Neumann-A commented Aug 17, 2021

Neumann-A commented Aug 17, 2021

JackBoosY commented Aug 17, 2021

Neumann-A commented Aug 17, 2021 • edited Loading

JackBoosY commented Aug 17, 2021 • edited Loading

Neumann-A commented Aug 17, 2021

JackBoosY commented Aug 18, 2021

JackBoosY commented Sep 1, 2021

ras0219-msft left a comment • edited Loading

Choose a reason for hiding this comment

ras0219-msft Sep 2, 2021

Choose a reason for hiding this comment

Neumann-A Sep 3, 2021

Choose a reason for hiding this comment

JackBoosY Sep 3, 2021 • edited Loading

Choose a reason for hiding this comment

ras0219-msft Sep 3, 2021

Choose a reason for hiding this comment

cenit commented Sep 3, 2021

JackBoosY Sep 3, 2021

Choose a reason for hiding this comment

JackBoosY Sep 3, 2021

Choose a reason for hiding this comment

Neumann-A commented Sep 3, 2021 • edited Loading

ras0219-msft commented Sep 3, 2021 • edited Loading

cenit Sep 6, 2021

Choose a reason for hiding this comment

JackBoosY commented Sep 18, 2021

JackBoosY commented Nov 19, 2021

JackBoosY commented Aug 17, 2021 •

edited by PhoebeHui

Loading

JackBoosY commented Aug 17, 2021 •

edited

Loading

JackBoosY commented Aug 17, 2021 •

edited

Loading

JackBoosY commented Aug 17, 2021 •

edited

Loading

Neumann-A commented Aug 17, 2021 •

edited

Loading

JackBoosY commented Aug 17, 2021 •

edited

Loading

ras0219-msft left a comment •

edited

Loading

JackBoosY Sep 3, 2021 •

edited

Loading

Neumann-A commented Sep 3, 2021 •

edited

Loading

ras0219-msft commented Sep 3, 2021 •

edited

Loading