> Our own FindLAPACK and also CMake FindLAPACK include both the BLAS library in the LAPACK_LIBRARIES (both tested!)
Interesting. I also see that in /usr/share/cmake/Modules/FindLAPACK.cmake:231-502: if(BLAS_FOUND) [...] else() message(STATUS "LAPACK requires BLAS") endif() For me the output is: -- Checking for module 'lapack' -- Found lapack, version 3.8.0 -- Found LAPACK: /usr/lib64/liblapack.so -- LAPACK found (/usr/lib64/liblapack.so) And not: -- LAPACK found (/usr/lib/i386-linux-gnu/liblapack.so;/usr/lib/i386-linux-gnu/libblas.so) I will investigate why there is this difference. > If I request CMake to use a library I assume it returns all needed libraries > to use the requested library - so I have not to check which other libs the > requested library is using internal. That is correct. But Hugin (via levmar) also uses BLAS, which at that point is no longer an implementation detail of LAPACK, but a direct dependency of Hugin. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/1892420 Title: levmar uses BLAS when built with LAPACK, but Hugin does not link against BLAS Status in Hugin: Invalid Status in hugin package in Gentoo Linux: New Bug description: ``` hugin-2019.2.0/src/foreign/levmar/misc_core.c:45:#define GEMM LM_MK_BLAS_NAME(gemm) ``` This function is a BLAS function: https://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms#Level_3 Thus, since levmar is built as a static library, Hugin itself should call `find_package(BLAS)` and `huginbase` should link against `BLAS_LIBRARIES`. Attached patch fixes this (in an admittedly slightly crude way) for me. To manage notifications about this bug go to: https://bugs.launchpad.net/hugin/+bug/1892420/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
