liblapacke: undefined reference to symbol 'dposv_'
up vote
1
down vote
favorite
I am trying to compile this library: https://github.com/dthuerck/culip but I get the following error during make:
[ 73%] Linking CXX executable culip-tests-la
/usr/bin/cmake -E cmake_link_script CMakeFiles/culip-tests-la.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -fopenmp -march=native -m64 -DGPU_BLAS -Wfatal-errors -O3 CMakeFiles/culip-tests-la.dir/tests/la/test_sparse.cc.o CMakeFiles/culip-tests-la.dir/tests/la/test_spmv.cc.o CMakeFiles/culip-tests-la.dir/tests/la/test_sqmr.cc.o -o culip-tests-la -L/gcc/home/sahmad/Desktop/culip/dependencies/mmio/lib -rdynamic /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt liblibutils.so liblibdatastructures.so liblibla.so liblibalgorithms.so -lmmio liblibtest.so -lblas -lhwloc -lgfortran -lblas -llapacke -lmmio ../dependencies/gtest/lib/libgtest.so ../dependencies/gtest/lib/libgtest_main.so /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt /usr/local/cuda-9.1/lib64/libcublas.so /usr/local/cuda-9.1/lib64/libcusparse.so /usr/local/cuda-9.1/lib64/libcusolver.so /usr/local/cuda-9.1/lib64/libcudadevrt.a -lblas -lhwloc -lgfortran -llapacke ../dependencies/gtest/lib/libgtest.so ../dependencies/gtest/lib/libgtest_main.so /usr/local/cuda-9.1/lib64/libcublas.so /usr/local/cuda-9.1/lib64/libcusparse.so /usr/local/cuda-9.1/lib64/libcusolver.so /usr/local/cuda-9.1/lib64/libcudadevrt.a /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt -Wl,-rpath,/gcc/home/sahmad/Desktop/culip/build:/gcc/home/sahmad/Desktop/culip/dependencies/mmio/lib:/gcc/home/sahmad/Desktop/culip/dependencies/gtest/lib:/usr/local/cuda-9.1/lib64
/usr/bin/ld: /gcc/home/sahmad/Downloads/lapack-3.8.0/liblapacke.a(lapacke_dposv_work.o): undefined reference to symbol 'dposv_'
//usr/lib/libopenblas.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
CMakeFiles/culip-tests-la.dir/build.make:171: recipe for target 'culip-tests-la' failed
make[2]: *** [culip-tests-la] Error 1
make[2]: Leaving directory '/gcc/home/sahmad/Desktop/culip/build'
CMakeFiles/Makefile2:72: recipe for target 'CMakeFiles/culip-tests-la.dir/all' failed
make[1]: *** [CMakeFiles/culip-tests-la.dir/all] Error 2
make[1]: Leaving directory '/gcc/home/sahmad/Desktop/culip/build'
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
I know this is a common error and I've tried following other's solutions on similar errors but as I have little experience with Ubuntu and C++, I couldn't solve it. It's obviously some kind of linking error and I tried linking the libraries in a different order, but no luck yet.
I am working on Ubuntu 16.04 with gcc 5.4.0 and CUDA 9.1.
Any help would be greatly appreciated.
makefile cmake linker
add a comment |
up vote
1
down vote
favorite
I am trying to compile this library: https://github.com/dthuerck/culip but I get the following error during make:
[ 73%] Linking CXX executable culip-tests-la
/usr/bin/cmake -E cmake_link_script CMakeFiles/culip-tests-la.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -fopenmp -march=native -m64 -DGPU_BLAS -Wfatal-errors -O3 CMakeFiles/culip-tests-la.dir/tests/la/test_sparse.cc.o CMakeFiles/culip-tests-la.dir/tests/la/test_spmv.cc.o CMakeFiles/culip-tests-la.dir/tests/la/test_sqmr.cc.o -o culip-tests-la -L/gcc/home/sahmad/Desktop/culip/dependencies/mmio/lib -rdynamic /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt liblibutils.so liblibdatastructures.so liblibla.so liblibalgorithms.so -lmmio liblibtest.so -lblas -lhwloc -lgfortran -lblas -llapacke -lmmio ../dependencies/gtest/lib/libgtest.so ../dependencies/gtest/lib/libgtest_main.so /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt /usr/local/cuda-9.1/lib64/libcublas.so /usr/local/cuda-9.1/lib64/libcusparse.so /usr/local/cuda-9.1/lib64/libcusolver.so /usr/local/cuda-9.1/lib64/libcudadevrt.a -lblas -lhwloc -lgfortran -llapacke ../dependencies/gtest/lib/libgtest.so ../dependencies/gtest/lib/libgtest_main.so /usr/local/cuda-9.1/lib64/libcublas.so /usr/local/cuda-9.1/lib64/libcusparse.so /usr/local/cuda-9.1/lib64/libcusolver.so /usr/local/cuda-9.1/lib64/libcudadevrt.a /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt -Wl,-rpath,/gcc/home/sahmad/Desktop/culip/build:/gcc/home/sahmad/Desktop/culip/dependencies/mmio/lib:/gcc/home/sahmad/Desktop/culip/dependencies/gtest/lib:/usr/local/cuda-9.1/lib64
/usr/bin/ld: /gcc/home/sahmad/Downloads/lapack-3.8.0/liblapacke.a(lapacke_dposv_work.o): undefined reference to symbol 'dposv_'
//usr/lib/libopenblas.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
CMakeFiles/culip-tests-la.dir/build.make:171: recipe for target 'culip-tests-la' failed
make[2]: *** [culip-tests-la] Error 1
make[2]: Leaving directory '/gcc/home/sahmad/Desktop/culip/build'
CMakeFiles/Makefile2:72: recipe for target 'CMakeFiles/culip-tests-la.dir/all' failed
make[1]: *** [CMakeFiles/culip-tests-la.dir/all] Error 2
make[1]: Leaving directory '/gcc/home/sahmad/Desktop/culip/build'
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
I know this is a common error and I've tried following other's solutions on similar errors but as I have little experience with Ubuntu and C++, I couldn't solve it. It's obviously some kind of linking error and I tried linking the libraries in a different order, but no luck yet.
I am working on Ubuntu 16.04 with gcc 5.4.0 and CUDA 9.1.
Any help would be greatly appreciated.
makefile cmake linker
Hi Cielaah, could you link the solutions you tried so others can check them more easily and maybe help you build from them?
– Silmathoron
Nov 22 at 15:31
1
From the command line, the relative order of linkingblas
andlapacke
libraries is:... -lblas -llapacke ... -lblas ... -lapacke
. According to that question, the second linking withblas
is ignored (as it is shared library), so there is effectively noblas
followedlapacke
in the command line, and you get this classic "undefined reference" error.
– Tsyvarev
Nov 22 at 17:22
If you want us to help you in fixing your code, you need to post part of this code, responsible for such linking order. The link to the repo isn't sufficient: it is off-site and quite large. Ideally, we want to have Minimal, Complete, and Verifiable example, which reproduces your problem, to be in the question post itself.
– Tsyvarev
Nov 22 at 17:29
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am trying to compile this library: https://github.com/dthuerck/culip but I get the following error during make:
[ 73%] Linking CXX executable culip-tests-la
/usr/bin/cmake -E cmake_link_script CMakeFiles/culip-tests-la.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -fopenmp -march=native -m64 -DGPU_BLAS -Wfatal-errors -O3 CMakeFiles/culip-tests-la.dir/tests/la/test_sparse.cc.o CMakeFiles/culip-tests-la.dir/tests/la/test_spmv.cc.o CMakeFiles/culip-tests-la.dir/tests/la/test_sqmr.cc.o -o culip-tests-la -L/gcc/home/sahmad/Desktop/culip/dependencies/mmio/lib -rdynamic /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt liblibutils.so liblibdatastructures.so liblibla.so liblibalgorithms.so -lmmio liblibtest.so -lblas -lhwloc -lgfortran -lblas -llapacke -lmmio ../dependencies/gtest/lib/libgtest.so ../dependencies/gtest/lib/libgtest_main.so /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt /usr/local/cuda-9.1/lib64/libcublas.so /usr/local/cuda-9.1/lib64/libcusparse.so /usr/local/cuda-9.1/lib64/libcusolver.so /usr/local/cuda-9.1/lib64/libcudadevrt.a -lblas -lhwloc -lgfortran -llapacke ../dependencies/gtest/lib/libgtest.so ../dependencies/gtest/lib/libgtest_main.so /usr/local/cuda-9.1/lib64/libcublas.so /usr/local/cuda-9.1/lib64/libcusparse.so /usr/local/cuda-9.1/lib64/libcusolver.so /usr/local/cuda-9.1/lib64/libcudadevrt.a /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt -Wl,-rpath,/gcc/home/sahmad/Desktop/culip/build:/gcc/home/sahmad/Desktop/culip/dependencies/mmio/lib:/gcc/home/sahmad/Desktop/culip/dependencies/gtest/lib:/usr/local/cuda-9.1/lib64
/usr/bin/ld: /gcc/home/sahmad/Downloads/lapack-3.8.0/liblapacke.a(lapacke_dposv_work.o): undefined reference to symbol 'dposv_'
//usr/lib/libopenblas.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
CMakeFiles/culip-tests-la.dir/build.make:171: recipe for target 'culip-tests-la' failed
make[2]: *** [culip-tests-la] Error 1
make[2]: Leaving directory '/gcc/home/sahmad/Desktop/culip/build'
CMakeFiles/Makefile2:72: recipe for target 'CMakeFiles/culip-tests-la.dir/all' failed
make[1]: *** [CMakeFiles/culip-tests-la.dir/all] Error 2
make[1]: Leaving directory '/gcc/home/sahmad/Desktop/culip/build'
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
I know this is a common error and I've tried following other's solutions on similar errors but as I have little experience with Ubuntu and C++, I couldn't solve it. It's obviously some kind of linking error and I tried linking the libraries in a different order, but no luck yet.
I am working on Ubuntu 16.04 with gcc 5.4.0 and CUDA 9.1.
Any help would be greatly appreciated.
makefile cmake linker
I am trying to compile this library: https://github.com/dthuerck/culip but I get the following error during make:
[ 73%] Linking CXX executable culip-tests-la
/usr/bin/cmake -E cmake_link_script CMakeFiles/culip-tests-la.dir/link.txt --verbose=1
/usr/bin/c++ -fPIC -fopenmp -march=native -m64 -DGPU_BLAS -Wfatal-errors -O3 CMakeFiles/culip-tests-la.dir/tests/la/test_sparse.cc.o CMakeFiles/culip-tests-la.dir/tests/la/test_spmv.cc.o CMakeFiles/culip-tests-la.dir/tests/la/test_sqmr.cc.o -o culip-tests-la -L/gcc/home/sahmad/Desktop/culip/dependencies/mmio/lib -rdynamic /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt liblibutils.so liblibdatastructures.so liblibla.so liblibalgorithms.so -lmmio liblibtest.so -lblas -lhwloc -lgfortran -lblas -llapacke -lmmio ../dependencies/gtest/lib/libgtest.so ../dependencies/gtest/lib/libgtest_main.so /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt /usr/local/cuda-9.1/lib64/libcublas.so /usr/local/cuda-9.1/lib64/libcusparse.so /usr/local/cuda-9.1/lib64/libcusolver.so /usr/local/cuda-9.1/lib64/libcudadevrt.a -lblas -lhwloc -lgfortran -llapacke ../dependencies/gtest/lib/libgtest.so ../dependencies/gtest/lib/libgtest_main.so /usr/local/cuda-9.1/lib64/libcublas.so /usr/local/cuda-9.1/lib64/libcusparse.so /usr/local/cuda-9.1/lib64/libcusolver.so /usr/local/cuda-9.1/lib64/libcudadevrt.a /usr/local/cuda-9.1/lib64/libcudart_static.a -lpthread -ldl -lrt -Wl,-rpath,/gcc/home/sahmad/Desktop/culip/build:/gcc/home/sahmad/Desktop/culip/dependencies/mmio/lib:/gcc/home/sahmad/Desktop/culip/dependencies/gtest/lib:/usr/local/cuda-9.1/lib64
/usr/bin/ld: /gcc/home/sahmad/Downloads/lapack-3.8.0/liblapacke.a(lapacke_dposv_work.o): undefined reference to symbol 'dposv_'
//usr/lib/libopenblas.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
CMakeFiles/culip-tests-la.dir/build.make:171: recipe for target 'culip-tests-la' failed
make[2]: *** [culip-tests-la] Error 1
make[2]: Leaving directory '/gcc/home/sahmad/Desktop/culip/build'
CMakeFiles/Makefile2:72: recipe for target 'CMakeFiles/culip-tests-la.dir/all' failed
make[1]: *** [CMakeFiles/culip-tests-la.dir/all] Error 2
make[1]: Leaving directory '/gcc/home/sahmad/Desktop/culip/build'
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
I know this is a common error and I've tried following other's solutions on similar errors but as I have little experience with Ubuntu and C++, I couldn't solve it. It's obviously some kind of linking error and I tried linking the libraries in a different order, but no luck yet.
I am working on Ubuntu 16.04 with gcc 5.4.0 and CUDA 9.1.
Any help would be greatly appreciated.
makefile cmake linker
makefile cmake linker
asked Nov 22 at 13:58
Cielaah
83
83
Hi Cielaah, could you link the solutions you tried so others can check them more easily and maybe help you build from them?
– Silmathoron
Nov 22 at 15:31
1
From the command line, the relative order of linkingblas
andlapacke
libraries is:... -lblas -llapacke ... -lblas ... -lapacke
. According to that question, the second linking withblas
is ignored (as it is shared library), so there is effectively noblas
followedlapacke
in the command line, and you get this classic "undefined reference" error.
– Tsyvarev
Nov 22 at 17:22
If you want us to help you in fixing your code, you need to post part of this code, responsible for such linking order. The link to the repo isn't sufficient: it is off-site and quite large. Ideally, we want to have Minimal, Complete, and Verifiable example, which reproduces your problem, to be in the question post itself.
– Tsyvarev
Nov 22 at 17:29
add a comment |
Hi Cielaah, could you link the solutions you tried so others can check them more easily and maybe help you build from them?
– Silmathoron
Nov 22 at 15:31
1
From the command line, the relative order of linkingblas
andlapacke
libraries is:... -lblas -llapacke ... -lblas ... -lapacke
. According to that question, the second linking withblas
is ignored (as it is shared library), so there is effectively noblas
followedlapacke
in the command line, and you get this classic "undefined reference" error.
– Tsyvarev
Nov 22 at 17:22
If you want us to help you in fixing your code, you need to post part of this code, responsible for such linking order. The link to the repo isn't sufficient: it is off-site and quite large. Ideally, we want to have Minimal, Complete, and Verifiable example, which reproduces your problem, to be in the question post itself.
– Tsyvarev
Nov 22 at 17:29
Hi Cielaah, could you link the solutions you tried so others can check them more easily and maybe help you build from them?
– Silmathoron
Nov 22 at 15:31
Hi Cielaah, could you link the solutions you tried so others can check them more easily and maybe help you build from them?
– Silmathoron
Nov 22 at 15:31
1
1
From the command line, the relative order of linking
blas
and lapacke
libraries is: ... -lblas -llapacke ... -lblas ... -lapacke
. According to that question, the second linking with blas
is ignored (as it is shared library), so there is effectively no blas
followed lapacke
in the command line, and you get this classic "undefined reference" error.– Tsyvarev
Nov 22 at 17:22
From the command line, the relative order of linking
blas
and lapacke
libraries is: ... -lblas -llapacke ... -lblas ... -lapacke
. According to that question, the second linking with blas
is ignored (as it is shared library), so there is effectively no blas
followed lapacke
in the command line, and you get this classic "undefined reference" error.– Tsyvarev
Nov 22 at 17:22
If you want us to help you in fixing your code, you need to post part of this code, responsible for such linking order. The link to the repo isn't sufficient: it is off-site and quite large. Ideally, we want to have Minimal, Complete, and Verifiable example, which reproduces your problem, to be in the question post itself.
– Tsyvarev
Nov 22 at 17:29
If you want us to help you in fixing your code, you need to post part of this code, responsible for such linking order. The link to the repo isn't sufficient: it is off-site and quite large. Ideally, we want to have Minimal, Complete, and Verifiable example, which reproduces your problem, to be in the question post itself.
– Tsyvarev
Nov 22 at 17:29
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
Lapacke is an interface to lapack: lapack is not embedded in lapacke. As a result, both need to be linked. Moreover, the order matters: all functions used in the library on the left must be defined by libraries on the right.
As a consequence, could you try to link -llapacke -llapack -lblas -lm
?
More specifically, at some point in the test, the function dposv_
is called and this function is implemented in Lapack, not in Lapacke. Indeed, Lapacke contains an interface LAPACKE_dposv()
, calling LAPACKE_dposv_work()
, calling LAPACK_dposv()
, that is LAPACK_GLOBAL(dposv,DPOSV)
, boiling down to dposv_
on your plateform.
In Cmake, if the lapack library is in your library search path, modifying the target_link_libraries()
in the CMakeLists.txt could locally do the trick.
target_link_libraries(culip-tests-la lapacke lapack blas m)
The best way to go would be to add the following commands to the CMakeLists.txt to make sure that Blas and Lapack are installed and found:
find_package(BLAS REQUIRED)
find_package(LAPACK REQUIRED)
The last line sets flags like LAPACK_LIBRARIES
and LAPACK_LINKER_FLAGS
as defined in FindLAPACK.html and FindLAPACK.cmake. Then (As in CMake link atlas and llapack):
target_compile_options(culip-tests-la ${LAPACK_LINKER_FLAGS})
target_link_libraries(culip-tests-la lapacke ${LAPACK_LIBRARIES})
The line find_package(BLAS REQUIRED)
is superfluous as it is almost the first thing done in FindLAPACK.cmake. Moreover the variable ${LAPACK_LIBRARIES}
likely contains something like -llapack -lblas -lm
or more. It can be printed by:
message( ${LAPACK_LIBRARIES} )
Thank you for your great insight and thorough answer! Adding -llapack to the linking fixed the problem for me. I also removed the second -lblas without a problem.
– Cielaah
Nov 23 at 11:16
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Lapacke is an interface to lapack: lapack is not embedded in lapacke. As a result, both need to be linked. Moreover, the order matters: all functions used in the library on the left must be defined by libraries on the right.
As a consequence, could you try to link -llapacke -llapack -lblas -lm
?
More specifically, at some point in the test, the function dposv_
is called and this function is implemented in Lapack, not in Lapacke. Indeed, Lapacke contains an interface LAPACKE_dposv()
, calling LAPACKE_dposv_work()
, calling LAPACK_dposv()
, that is LAPACK_GLOBAL(dposv,DPOSV)
, boiling down to dposv_
on your plateform.
In Cmake, if the lapack library is in your library search path, modifying the target_link_libraries()
in the CMakeLists.txt could locally do the trick.
target_link_libraries(culip-tests-la lapacke lapack blas m)
The best way to go would be to add the following commands to the CMakeLists.txt to make sure that Blas and Lapack are installed and found:
find_package(BLAS REQUIRED)
find_package(LAPACK REQUIRED)
The last line sets flags like LAPACK_LIBRARIES
and LAPACK_LINKER_FLAGS
as defined in FindLAPACK.html and FindLAPACK.cmake. Then (As in CMake link atlas and llapack):
target_compile_options(culip-tests-la ${LAPACK_LINKER_FLAGS})
target_link_libraries(culip-tests-la lapacke ${LAPACK_LIBRARIES})
The line find_package(BLAS REQUIRED)
is superfluous as it is almost the first thing done in FindLAPACK.cmake. Moreover the variable ${LAPACK_LIBRARIES}
likely contains something like -llapack -lblas -lm
or more. It can be printed by:
message( ${LAPACK_LIBRARIES} )
Thank you for your great insight and thorough answer! Adding -llapack to the linking fixed the problem for me. I also removed the second -lblas without a problem.
– Cielaah
Nov 23 at 11:16
add a comment |
up vote
1
down vote
accepted
Lapacke is an interface to lapack: lapack is not embedded in lapacke. As a result, both need to be linked. Moreover, the order matters: all functions used in the library on the left must be defined by libraries on the right.
As a consequence, could you try to link -llapacke -llapack -lblas -lm
?
More specifically, at some point in the test, the function dposv_
is called and this function is implemented in Lapack, not in Lapacke. Indeed, Lapacke contains an interface LAPACKE_dposv()
, calling LAPACKE_dposv_work()
, calling LAPACK_dposv()
, that is LAPACK_GLOBAL(dposv,DPOSV)
, boiling down to dposv_
on your plateform.
In Cmake, if the lapack library is in your library search path, modifying the target_link_libraries()
in the CMakeLists.txt could locally do the trick.
target_link_libraries(culip-tests-la lapacke lapack blas m)
The best way to go would be to add the following commands to the CMakeLists.txt to make sure that Blas and Lapack are installed and found:
find_package(BLAS REQUIRED)
find_package(LAPACK REQUIRED)
The last line sets flags like LAPACK_LIBRARIES
and LAPACK_LINKER_FLAGS
as defined in FindLAPACK.html and FindLAPACK.cmake. Then (As in CMake link atlas and llapack):
target_compile_options(culip-tests-la ${LAPACK_LINKER_FLAGS})
target_link_libraries(culip-tests-la lapacke ${LAPACK_LIBRARIES})
The line find_package(BLAS REQUIRED)
is superfluous as it is almost the first thing done in FindLAPACK.cmake. Moreover the variable ${LAPACK_LIBRARIES}
likely contains something like -llapack -lblas -lm
or more. It can be printed by:
message( ${LAPACK_LIBRARIES} )
Thank you for your great insight and thorough answer! Adding -llapack to the linking fixed the problem for me. I also removed the second -lblas without a problem.
– Cielaah
Nov 23 at 11:16
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Lapacke is an interface to lapack: lapack is not embedded in lapacke. As a result, both need to be linked. Moreover, the order matters: all functions used in the library on the left must be defined by libraries on the right.
As a consequence, could you try to link -llapacke -llapack -lblas -lm
?
More specifically, at some point in the test, the function dposv_
is called and this function is implemented in Lapack, not in Lapacke. Indeed, Lapacke contains an interface LAPACKE_dposv()
, calling LAPACKE_dposv_work()
, calling LAPACK_dposv()
, that is LAPACK_GLOBAL(dposv,DPOSV)
, boiling down to dposv_
on your plateform.
In Cmake, if the lapack library is in your library search path, modifying the target_link_libraries()
in the CMakeLists.txt could locally do the trick.
target_link_libraries(culip-tests-la lapacke lapack blas m)
The best way to go would be to add the following commands to the CMakeLists.txt to make sure that Blas and Lapack are installed and found:
find_package(BLAS REQUIRED)
find_package(LAPACK REQUIRED)
The last line sets flags like LAPACK_LIBRARIES
and LAPACK_LINKER_FLAGS
as defined in FindLAPACK.html and FindLAPACK.cmake. Then (As in CMake link atlas and llapack):
target_compile_options(culip-tests-la ${LAPACK_LINKER_FLAGS})
target_link_libraries(culip-tests-la lapacke ${LAPACK_LIBRARIES})
The line find_package(BLAS REQUIRED)
is superfluous as it is almost the first thing done in FindLAPACK.cmake. Moreover the variable ${LAPACK_LIBRARIES}
likely contains something like -llapack -lblas -lm
or more. It can be printed by:
message( ${LAPACK_LIBRARIES} )
Lapacke is an interface to lapack: lapack is not embedded in lapacke. As a result, both need to be linked. Moreover, the order matters: all functions used in the library on the left must be defined by libraries on the right.
As a consequence, could you try to link -llapacke -llapack -lblas -lm
?
More specifically, at some point in the test, the function dposv_
is called and this function is implemented in Lapack, not in Lapacke. Indeed, Lapacke contains an interface LAPACKE_dposv()
, calling LAPACKE_dposv_work()
, calling LAPACK_dposv()
, that is LAPACK_GLOBAL(dposv,DPOSV)
, boiling down to dposv_
on your plateform.
In Cmake, if the lapack library is in your library search path, modifying the target_link_libraries()
in the CMakeLists.txt could locally do the trick.
target_link_libraries(culip-tests-la lapacke lapack blas m)
The best way to go would be to add the following commands to the CMakeLists.txt to make sure that Blas and Lapack are installed and found:
find_package(BLAS REQUIRED)
find_package(LAPACK REQUIRED)
The last line sets flags like LAPACK_LIBRARIES
and LAPACK_LINKER_FLAGS
as defined in FindLAPACK.html and FindLAPACK.cmake. Then (As in CMake link atlas and llapack):
target_compile_options(culip-tests-la ${LAPACK_LINKER_FLAGS})
target_link_libraries(culip-tests-la lapacke ${LAPACK_LIBRARIES})
The line find_package(BLAS REQUIRED)
is superfluous as it is almost the first thing done in FindLAPACK.cmake. Moreover the variable ${LAPACK_LIBRARIES}
likely contains something like -llapack -lblas -lm
or more. It can be printed by:
message( ${LAPACK_LIBRARIES} )
answered Nov 22 at 22:05
francis
6,71921831
6,71921831
Thank you for your great insight and thorough answer! Adding -llapack to the linking fixed the problem for me. I also removed the second -lblas without a problem.
– Cielaah
Nov 23 at 11:16
add a comment |
Thank you for your great insight and thorough answer! Adding -llapack to the linking fixed the problem for me. I also removed the second -lblas without a problem.
– Cielaah
Nov 23 at 11:16
Thank you for your great insight and thorough answer! Adding -llapack to the linking fixed the problem for me. I also removed the second -lblas without a problem.
– Cielaah
Nov 23 at 11:16
Thank you for your great insight and thorough answer! Adding -llapack to the linking fixed the problem for me. I also removed the second -lblas without a problem.
– Cielaah
Nov 23 at 11:16
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53432594%2fliblapacke-undefined-reference-to-symbol-dposv%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Hi Cielaah, could you link the solutions you tried so others can check them more easily and maybe help you build from them?
– Silmathoron
Nov 22 at 15:31
1
From the command line, the relative order of linking
blas
andlapacke
libraries is:... -lblas -llapacke ... -lblas ... -lapacke
. According to that question, the second linking withblas
is ignored (as it is shared library), so there is effectively noblas
followedlapacke
in the command line, and you get this classic "undefined reference" error.– Tsyvarev
Nov 22 at 17:22
If you want us to help you in fixing your code, you need to post part of this code, responsible for such linking order. The link to the repo isn't sufficient: it is off-site and quite large. Ideally, we want to have Minimal, Complete, and Verifiable example, which reproduces your problem, to be in the question post itself.
– Tsyvarev
Nov 22 at 17:29