levmar uses BLAS when built with LAPACK, but Hugin does not link against BLAS

What is the error the build system report without the patch?

Also before applying the patch I would be interested in a comparison between self-contained levmar and levmar+LAPACK.
The photometric optimizer is the only part of Hugin which is using the embedded levmar lib. I don't know if using LAPACK (+BLAS) brings a speed or stability improvement. If there is no improvement of using LAPACK then maybe the LAPACK detection should be removed. When there is an improvement with LAPACK I would be interested how large this improvement is.

> 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 -Wl,--as-needed -Wl,--hash-style=gnu -fopenmp CMakeFiles/cpclean.dir/cpclean.cpp.o -o cpclean -Wl,-rpath,/tmp/portage/media-gfx/hugin-2019.2.0/work/hugin-2019.2.0_build/src/hugin_base: ../hugin_base/libhuginbase.so.0.0 /usr/lib64/libpano13.so ../foreign/levmar/libhuginlevmar.a /usr/lib64/libGLEW.so /usr/lib64/libboost_filesystem-mt.so /usr/lib64/libboost_system-mt.so /usr/lib64/liblapack.so /usr/lib64/libfftw3.so /usr/lib64/libvigraimpex.so /usr/lib64/libImath.so /usr/lib64/libIlmImf.so /usr/lib64/libIex.so /usr/lib64/libHalf.so /usr/lib64/libIlmThread.so /usr/lib64/libz.so /usr/lib64/libjpeg.so /usr/lib64/libtiff.so /usr/lib64/libpng.so /usr/lib64/libz.so /usr/lib64/libz.so /usr/lib64/libexiv2.so /usr/lib64/liblcms2.so -pthread /usr/lib64/libX11.so /usr/lib64/libpano13.so /usr/lib64/libboost_filesystem-mt.so /usr/lib64/libboost_system-mt.so /usr/lib64/liblapack.so /usr/lib64/libGL.so /usr/lib64/libGLU.so /usr/lib64/libGLEW.so /usr/lib64/libsqlite3.so /usr/lib64/libvigraimpex.so /usr/lib64/libjpeg.so /usr/lib64/libpng.so /usr/lib64/libtiff.so /usr/lib64/libexiv2.so /usr/lib64/liblcms2.so
../hugin_base/libhuginbase.so.0.0: error: undefined reference to 'dgemm_'
collect2: error: ld returned 1 exit status

You can find more details at: https://bugs.gentoo.org/738274

> 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 it is a good idea to remove it. Maybe someone will complain about the removal and provide you with insights on why the option was originally introduced.

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 CMakeModules/FindLAPACK.cmake for this BLAS variant.

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 LAPACK target only include the LAPACK library and not BLAS, since programs using BLAS should probably explicitly link against the BLAS target.

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.

Also looking into CMakes own FindLAPACK:
at the beginning there is a note:
``LAPACK_LIBRARIES`` uncached list of libraries (using full path name) to link against to use LAPACK
as I wrote above.
Also scrolling down I find:
find_package(BLAS)
So also CMake own FindLAPACK should also find BLAS.

I tested now also on Ubuntu. Our own FindLAPACK and also CMake FindLAPACK include both the BLAS library in the LAPACK_LIBRARIES (both tested!)
From the log:
LAPACK found (/usr/lib/i386-linux-gnu/liblapack.so;/usr/lib/i386-linux-gnu/libblas.so)

So - without more information - I don't see the point of explicitly searching for BLAS.
So maybe Gentoo is also modifying files in CMake(?)/LAPACK(?)/BLAS(?) - as deleting the file in Hugins build system, which breaks then later.

> 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.