> 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
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.
So FindPackage should hide the internal details for the user - this is what our
own FindLAPACK does.
Thank you for taking a look.
Gentoo's package manager removes that file in favour of the one provided
by CMake itself:
❯ q file -v /usr/share/cmake/Modules/FindLAPACK.cmake
dev-util/cmake-3.18.1: /usr/share/cmake/Modules/FindLAPACK.cmake
Now one might argue that CMake is correct in having the
I checked the build system. Our FindPackage(LAPACK) does already search
for the blas libraries. So maybe you are using a slightly different name
of the BLAS library (other implementation) so that CMake does not pick
up this variant. So the easiest way to fix would be to update
Launchpad has imported 2 comments from the remote bug at
https://bugs.gentoo.org/show_bug.cgi?id=738274.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
> Also before applying the patch I would be interested in a comparison
between self-contained levmar and levmar+LAPACK. [...] If there is no
improvement of using LAPACK then maybe the LAPACK detection should be
removed.
If the benefits of this build-system feature of Hugin are unknown, I
agree
> What is the error the build system report without the patch?
cd /tmp/portage/media-gfx/hugin-2019.2.0/work/hugin-2019.2.0_build/src/tools &&
/usr/bin/cmake -E cmake_link_script CMakeFiles/cpclean.dir/link.txt --verbose=1
/usr/sbin/x86_64-pc-linux-gnu-g++ -pipe -O2 -march=znver1 -Wl,-O1
7 matches
Mail list logo
