[lapack-reference] Fixed lapack.lib not being found when linking using cmake under Windows

[jimwang118]

Fixes #38009
Remove the statement renaming liblapack.lib.

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

Usage test pass with following triplets:

x64-windows

[Neumann-A]

No. There is a test port in vcpkg which makes sure lapack can be found the way it is.

[Neumann-A]

And the canonical way to use lapack is via find_package(Lapack) via module and not config mode

[jimwang118]

And the canonical way to use lapack is via find_package(Lapack) via module and not config mode

When using config mode in the original usage, it will prompt that lapack.lib cannot be opened when compiling the generated project.

find_package(lapack CONFIG REQUIRED)
target_link_libraries(main PRIVATE lapack)

[dg0yt]

Well, the guidelines disallow renaming after the build because of CMake config.

Could we just patch out these lines:
https://github.com/Reference-LAPACK/lapack/blob/7295ac130f1d880e10c4412b6b524498f0538635/CMakeLists.txt#L14-L15

[BillyONeal]

This work probably got reset by merging #24327

[Neumann-A]

The changes of this PR ignoring WS changes looks strange to me.

[BillyONeal]

The change to lapack-reference looks correct to me (they just implement https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#do-not-rename-binaries-outside-the-names-given-by-upstream ). Can you explain how the opencv4 and openmvs changes are related?

Thanks! <3

[jimwang118]

The change to lapack-reference looks correct to me (they just implement https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#do-not-rename-binaries-outside-the-names-given-by-upstream ). Can you explain how the opencv4 and openmvs changes are related?

Thanks! <3

The reason for modifying opencv4 and openmvs is that when ci is running, it prompts: opencv4 cannot find the flatbuffers header file, so the flatbuffers search method is fixed. openmvs prompts that zstd cannot be found when connecting, because #32309 is not merged yet and FindBoost only knows about transitive usage requirements within boost itself.

[patrikhuber]

@jimwang118 Actually, it looks like this PR broke opencv4. vcpkg install opencv4[core] now fails with an error that flatbuffers was not found. vcpkg install opencv4 doesn't fail because that pulls in flatbuffers as a vcpkg dependency. However I don't think opencv4[core] needs flatbuffers, so it should not fail and not even look for flatbuffers. Before this PR (vcpkg baseline from Sep 2023), vcpkg install opencv4[core] installed fine, without needing flatbuffers.

So what I think might be happening is that the old method include(cmake/OpenCVDetectFlatbuffers.cmake) had some conditional logic inside to not require/find flatbuffers when only opencv4[core] is requested, and the new line find_package(flatbuffers CONFIG REQUIRED) is unconditionally requesting flatbuffers (which is likely wrong).

[jimwang118]

@jimwang118 Actually, it looks like this PR broke opencv4. vcpkg install opencv4[core] now fails with an error that flatbuffers was not found. vcpkg install opencv4 doesn't fail because that pulls in flatbuffers as a vcpkg dependency. However I don't think opencv4[core] needs flatbuffers, so it should not fail and not even look for flatbuffers. Before this PR (vcpkg baseline from Sep 2023), vcpkg install opencv4[core] installed fine, without needing flatbuffers.

So what I think might be happening is that the old method include(cmake/OpenCVDetectFlatbuffers.cmake) had some conditional logic inside to not require/find flatbuffers when only opencv4[core] is requested, and the new line find_package(flatbuffers CONFIG REQUIRED) is unconditionally requesting flatbuffers (which is likely wrong).

This issue is fixing by PR 38594.

[patrikhuber]

Ah great, thanks! I think that PR wasn't merged yet when I was running into the problem yesterday. I'll pull the latest vcpkg now.