[lapack] Use system lapack on macos

[seanwarren]

Describe the pull request

• What does your PR fix? Fixes #
  Using dlib on mac os x fails with the following error:

Undefined symbols for architecture x86_64:
  "__gfortran_concat_string", referenced from:
      _dormtr_ in liblapack.a(dormtr.f.o)
      _dormql_ in liblapack.a(dormql.f.o)
      _dormqr_ in liblapack.a(dormqr.f.o) 

This PR simply removes the dependency on Reference-Lapack on macos, which provides it's own lapack implementation.

• Which triplets are supported/not supported? Have you updated the CI baseline?

• Does your PR follow the maintainer guide?

[Neumann-A]

https://stackoverflow.com/questions/55508457/how-to-fix-undefined-reference-to-gfortran-concat-string-and-to-gfortran-etim
cc @cenit for opinion.

[Neumann-A]

Ah yes looking at FindLAPACK.cmake in the other PR I am against this change. If you want to generally link against system lapack on OSX have a cmake toolchain which sets BLA_VENDOR to Apple and skips the lapack-reference installation in the triplet or reintroduce the external feature for the lapack/blas metaports.

[seanwarren]

Hi @Neumann-A, thanks for your feedback. At the moment the reference-lapack package is not usable on macos without manually linking to gfortran; presumably this is a bug? I'm not sure what the best way to fix this is (aside from using the system lapack)

[Neumann-A]

@seanwarren: I think the trick here is to figure out why LAPACK_LIBRARIES does not contain all required libraries? Maybe also a look at BLAS_LIBRARIES is required. From what I see in FindLAPACK.cmake should check which libs are required for successfully linkage. Maybe a vcpkg_configure_cmake run with option --trace or --trace-expand gives further info. Also check what cmake variable dlib uses to link against lapack.

[Neumann-A]

Ah looks like dlib is doing its own shenanigans using blas/lapack. So that probably needs a patch to dlib/cmake_utils/find_blas.cmake in dlib.

[cenit]

Sorry for late reply. I didn't experience the problem but I saw that as of now vcpkg is not using the lapack-config.cmake that is generated during build, which was a little broken but maybe better than the module...
I will investigate it more in the weekend if necessary. On the other hand, if you have problems @seanwarren I suggest you to override the blas and the lapack port to skip them in osx, not pushing a PR to remove it from some ports.

[JackBoosY]

For this issue, I wish #21479 will also consider this scenes.

[JackBoosY]

Since the system does not necessarily include lapack, I hope to still use lapack in vcpkg.

[ras0219-msft]

@seanwarren Could you look at #21479 and comment on it about your scenario?

[strega-nil-ms]

Closing this PR as it's very out of date; if people have something else to say, please do it in #21479.

Thanks so much for the PR, and sorry for leaving it for so long!

[cenit]

Since the system does not necessarily include lapack, I hope to still use lapack in vcpkg.

Accelerate framework, which includes lapack, is always installed on macos