cminpack
cminpack copied to clipboard
undefined reference to `cblas_dnrm2'
Hello, I think the cmake is not linking to cblas as it should:
CMakeFiles/cminpack.dir/objects.a(enorm.c.obj): In function `enorm':
/home/xantares/projects/aur-scripts/mingw-w64-cminpack/src/cminpack-1.3.6/enorm.c:53: undefined reference to `cblas_dnrm2'
Adding target_link_libraries(cminpack PUBLIC cblas)
manually solves the problem, but this needs cleaner detection, for example if needing openblas. Maybe be linking to blas/cblas is private.
Maybe there's cmake stuff to detect the right cblas somewhere?
feel free to fix the CMakefile and file a pull request for this one
cminpack should link to cblas as it uses cblas name mangling:
./enorm.c:53: return cblas_dnrm2(n, x, 1);
however cmake enables cblas symbols by default even if cblas is not linked:
target_compile_definitions(cminpack PUBLIC -DUSE_CBLAS)
this doesnt show up in makefile as its only enabled for the long version:
CFLAGS_L=$(CFLAGS) -DUSE_CBLAS -DUSE_LAPACK
@xantares Can you clarify the conditions in which the build fails? I checked out cminpack before the merge of #21 and could build with -DUSE_CBLAS just fine on Arch and Fedora.
I would like to go back to CMake's default find_package(BLAS)
because the FindCBLAS you added in #21 doesn't support either openblas or flexiblas whereas CMake's FindBLAS does, so switching to it seems simpler (than continuously patching a vendored FindBLAS).
+1 on using cmake's FindBLAS. @anntzer can you prepare a PR?
it does support openblas or flexiblas, you just have to specify CBLAS_LIBRARIES variable using just FindBLAS could lead to other issues because it just check for the regular blas symbols, not the cblas ones
Ah, I see, it's basically https://gitlab.kitware.com/cmake/cmake/-/issues/19381 (i.e. blas!=cblas)? I guess the practical solution may be to just add more entries in the vendored FindCBLAS.cmake then :( ... or possibly just switch to using the (fortran) blas API?