I have installed the lapack library using the following commands:
sudo apt-get install liblapack-dev
In synaptic I have checked if everything was installed and it sounds good:
I would like to compile the g2o library which use liblaback but by doing cmake I have the following output:
CMake Error at cmake_modules/FindLAPACK.cmake:247 (message): A
required library with LAPACK API not found. Please specify library
location. Call Stack (most recent call first): CMakeLists.txt:75
(FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
I'm pretty sure that It's not because the CmakeList file and all the Cmake file including for example the FindLAPACK.cmake (can find it there) file because I remember to have compiled it well before using another computer with Ubuntu 14.04.
So now I don't know what is the problem. I tried to uninstall, purge and then install it again but still the same issue.
I also checked the /etc/ld.so.conf in case and it contains
include /etc/ld.so.conf.d/*.conf
/usr/local/lib
I did then to be sure
sudo ldconfig -p
I noticed that the library is on /usr/lib
For example:
/usr/lib/liblapack.so
/usr/lib/liblapack.so.3
/usr/lib/liblapack.so.3gf
/etc/alternatives/liblapack.so /etc/alternatives/liblapack.so.3
/etc/alternatives/liblapack.so.3gf /usr/lib/liblapack.so
/usr/lib/liblapack.so.3 /usr/lib/liblapack.so.3gf
/usr/lib/atlas-base/atlas/liblapack.so
/usr/lib/atlas-base/atlas/liblapack.so.3
/usr/lib/atlas-base/atlas/liblapack.so.3.0
/usr/lib/lapack/liblapack.so /usr/lib/lapack/liblapack.so.3
/usr/lib/lapack/liblapack.so.3.0
/var/lib/dpkg/alternatives/liblapack.so
/var/lib/dpkg/alternatives/liblapack.so.3
If I take a look on the Cmake file error, I have those lines inside:
/usr/bin/ld: /usr/local/lib/liblapack.a(xerbla.f.o): undefined
reference to symbol '_gfortran_string_len_trim##GFORTRAN_1.0'
//usr/lib/x86_64-linux-gnu/libgfortran.so.3: error adding symbols: DSO
missing from command line collect2: error: ld returned 1 exit status
But I checked and Gfortran is well installed also.
Do you have any idea ? I getting crazy about it.
Related
Operating system: macOS Catalina
I have a project that has a file called CMakeLists.txt. I ran cmake and then make, but the make command failed:
/Users/blablabla/Downloads/myproject/src/main.cpp:10:10: fatal error:
'openssl/evp.h' file not found
#include <openssl/evp.h>
I tried reinstalling OpenSSL via homebrew, linking the libraries but it still gave this error.
What am I could be doing wrong?
Any help would be highly appreciated
either openssl's dev library is not installed, or the g++ command that cmake generates probably is missing a -I.
try sudo apt-get install libssl-dev first and if that doesn't work, make sure the openssl include dir is provided to g++.
according to https://cmake.org/cmake/help/v3.6/module/FindOpenSSL.html, it creates an env var of OPENSSL_INCLUDE_DIR
edit: just noticed you're on OSX. you can install the the dev libssl package with brew install openssl
When building the docker image of a c++ project I'm facing issues when compiling the project inside the docker image because of a library linking issue
Docker file which is in the https://github.com/chinthakarukshan/jasminegraph/tree/master/docker location builds a docker image on top of ubuntu base image installing the necessary libraries required by the project. When compiling the project I'm getting a library linking issue and fails building the project with below error.
/usr/bin/ld: cannot find -lsqlite3
collect2: error: ld returned 1 exit status
make[3]: *** [JasmineGraph] Error 1
sqlite3 library is already installed in the Dockerfile. But it fails when linking the library.
Below is the cmake code which links the sqlite3 library with the project.
target_link_libraries(JasmineGraph sqlite3)
Below is the link to the corresponding CMakeList file.
https://github.com/chinthakarukshan/jasminegraph/blob/master/CMakeLists.txt
You need to install dev version:
RUN apt-get install -y libsqlite3-dev
I've reproduced this symptom on two computers now, cmake seems to no longer look in /usr/local/lib (or more properly, $(brew --prefix)/lib) for Homebrew-provided libraries since upgrading my machine to macOS Mojave.
Although there are ways to circumvent this (e.g. search for homebrew prefix using EXECUTE_PROCESS; add the result to LINK_LIBRARIES(...) command) none are ideal. What changed in Mojave to break this behavior?
The temporary workaround is to add the following to CMakeLists.txt:
# WARNING: Don't hard-code this path
LINK_DIRECTORIES(/usr/local/lib)
I've already tried brew doctor and updated all homebrew packages to no avail.
The specific error that cmake (make) shows is:
ld: library not found for -l<somelib>
I've asked the question on the Homebrew forums and the Apple developer forums.
Ran into a related (?) issue while trying to pip install psycopg2 in a Django app under OS X Mojave (10.14). I was getting the following errors:
ld: library not found for -lssl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: command 'clang' failed with exit status 1
The short explanation: « As of High Sierra, /usr/local is no longer
chown-able... »
The solution: change permissions for /usr/local to allow Homebrew to
create links.
I adapted the solution to my needs. Then I was finally able to run pip install psycopg2. Here is the sequence of commands (update: inside your project root i.e. where you see manage.py).
First
sudo chown -R $(whoami) $(brew --prefix)/*
Then
brew reinstall openssl
export LDFLAGS="-L/usr/local/opt/openssl/lib"
export CPPFLAGS="-I/usr/local/opt/openssl/include"
pip install psycopg2
I've isolated this to the following change in the VERBOSE=1 make logs...
High Sierra (<=10.13) and below did NOT use the -isysroot command.
Mojave (>=10.14) DOES use the -isysroot command.
From gnu.org:
-isysroot <dir>
This option is like the --sysroot option, but applies only to header files (except for Darwin targets, where it applies to both header files and libraries). See the --sysroot option for more information.
So this flag specifically clobbers the lib search path only on Apple. This results in the compilation never looking in the standard ld locations, which can be seen by typing ld -v dummy.
Library search paths:
/usr/lib
/usr/local/lib
Why does cmake do this? My thought is it was to fix the /usr/local/include issues introduced with the new Mojave SDK behavior.
Unfortunately, I can't find a cmake compile flag to add the default library search paths back in. For now the only solution I've found is to add the following to my project:
IF(APPLE)
# Fix linking on 10.14+. See https://stackoverflow.com/questions/54068035
LINK_DIRECTORIES(/usr/local/lib)
ENDIF()
I'm not sure if this is a behavior that warrants an upstream cmake patch. If there is a better solution, please provide it.
I'm new to C/C++ and am trying to build and run ttwatch from github locally on an Ubuntu machine (Trusty Tahr). Instructions include installing some libraries first: cmake, openssl, curl, libusb, and include a note to install the "-dev" versions (eg. libssl-dev, libcurl-dev, libusb-1.0-0-dev). I'm having some trouble with libusb. I see questions about this all over the internet, but haven't yet found a solution that works.
Running cmake . appears to work fine:
meowmeow#kittytown:~/code/ttwatch$ cmake .
-- Enabled daemon function
-- Found libusb-1.0:
-- - Includes: /usr/include/libusb-1.0
-- - Libraries: /usr/lib/x86_64-linux-gnu/libusb.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/meowmeow/code/ttwatch
But running make shows that libusb is not being located properly:
meowmeow#kittytown:~/code/ttwatch$ make
[ 42%] Built target libttbin
[ 42%] Built target libttwatch
[ 42%] Built target ttbincnv
[ 42%] Built target ttbinmod
[ 42%] Built target manifest
Linking CXX executable ttwatch
CMakeFiles/ttwatch.dir/src/ttwatch.c.o: In function `main':
/home/meowmeow/code/ttwatch/src/ttwatch.c:1618: undefined reference to `libusb_init'
/home/meowmeow/code/ttwatch/src/ttwatch.c:1796: undefined reference to `libusb_exit'
...
If I check /usr/includes/, I see libusb:
meowmeow#kittytown:~/code/ttwatch$ ls /usr/include/libusb-1.0/libusb.h
/usr/include/libusb-1.0/libusb.h
And dpkg shows:
meowmeow#kittytown:~/code/ttwatch$ dpkg -L libusb-1.0-0-dev
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/pkgconfig
/usr/lib/x86_64-linux-gnu/pkgconfig/libusb-1.0.pc
/usr/lib/x86_64-linux-gnu/libusb-1.0.a
/usr/share
/usr/share/doc
/usr/share/doc/libusb-1.0-0-dev
/usr/share/doc/libusb-1.0-0-dev/copyright
/usr/include
/usr/include/libusb-1.0
/usr/include/libusb-1.0/libusb.h
/usr/lib/x86_64-linux-gnu/libusb-1.0.so
/usr/share/doc/libusb-1.0-0-dev/README
/usr/share/doc/libusb-1.0-0-dev/changelog.Debian.gz
meowmeow#kittytown:~/code/ttwatch$ dpkg -L libusb-1.0-0
/.
/lib
/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu/libusb-1.0.so.0.1.0
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libusb-1.0-0
/usr/share/doc/libusb-1.0-0/README
/usr/share/doc/libusb-1.0-0/copyright
/usr/share/doc/libusb-1.0-0/changelog.Debian.gz
/lib/x86_64-linux-gnu/libusb-1.0.so.0
The file ttwatch/includes/libttwatch.h includes libusb as #include <libusb.h>, and I've tried modifying that to #include <libusb-1.0/libusb.h>, in hopes of better matching my /usr/includes/ files, but that didn't change the error output.
Any help would be greatly appreciated!
EDIT:
Using make VERBOSE=1does show -lusb, and not -lusb-1.0:
...
/usr/bin/c++ -g CMakeFiles/ttwatch.dir/src/ttwatch.c.o CMakeFiles/ttwatch.dir/src/log.c.o CMakeFiles/ttwatch.dir/src/options.c.o CMakeFiles/ttwatch.dir/src/json.c.o CMakeFiles/ttwatch.dir/src/download.c.o CMakeFiles/ttwatch.dir/src/firmware.c.o CMakeFiles/ttwatch.dir/src/misc.c.o CMakeFiles/ttwatch.dir/src/get_activities.c.o CMakeFiles/ttwatch.dir/src/update_gps.c.o CMakeFiles/ttwatch.dir/src/set_time.c.o -o ttwatch -rdynamic libttwatch.a libttbin.a -lusb -lssl -lcrypto -lcurl
And libusb.so appears to exist:
meowmeow#kittytown:~/code/ttwatch$ dpkg-query -S /usr/lib/x86_64-linux-gnu/libusb.so
libusb-dev: /usr/lib/x86_64-linux-gnu/libusb.so
I tried uninstalling libusb-dev (sudo apt-get remove libusb-dev) and installed libusb-1.0 (sudo apt-get install libusb-1.0) to see if that would solve the issue. I now have a /usr/lib/x86_64-linux-gnu/libusb-1.0.so (note the 1.0) instead, but am now getting this from make:
make[2]: *** No rule to make target /usr/lib/x86_64-linux-gnu/libusb.so', needed by ttwatch'. Stop.
I was not aware that Debian has the packages libusb-dev and
libusb-1.0-dev. From the package information I cannot tell why there are 2
packages for the same library, perhaps libusb-dev is an older version with a
different API and other packages might still have that as a dependency. So
removing the package might not be a good idea, unless you don't care/need
packages depending on libusb-dev, in which case you can do apt-get purge
libusb-dev && apt-get autoremove. Be ware that this might uninstall
packages that you need. So do it only if you know what you are doing.
I did not expect that Debian allows you to install both packages at the same
time, but this could be if the APIs of both libraries are different and don't
conflict with each other.
This seems to confuse cmake, which somehow cannot handle when both libraries
are simultaneously installed. I've gone through the issues page and I
haven't found an issue relating to that. So if you cannot manage to build it,
I'd suggest that you go to the issue page, if you don't have an github
account, create one and leave a bug report about building the package when
libusb-dev and libusb-1.0-dev are simultaneously installed.
Another option would be to make a small modification in the file cmake_modules/FindLibUSB.cmake before you do
$ mkdir build && cd build
$ cmake ..
Find the line find_library(LIBUSB_1_LIBRARY, on the current stable version it is line 62. The next line is NAMES
and the next line is usb-1.0 usb. Remove the usb from that, so that
find_library only searches for libusb-1.0. Save the file and then you can do
$ mkdir build && cd build
$ cmake ..
This should fix the problem.
I'm trying to build OpenCV 3.0.0 on a Raspberry Pi 2 running Raspbian Jessie. After installing all dependencies, I tried running cmake with the following parameters: cmake -D CMAKE_C_COMPILER=/usr/bin/gcc -D CMAKE_CXX_COMPILER=/usr/bin/c++ -D CMAKE_BUILD_TYPE=Release -D CMAKE_INSTALL_PREFIX=/usr/local ..
But then I got the following error.
CMake Error: Error in cmake code at
/usr/share/cmake-3.0/Modules/CMakeDetermineCXXCompiler.cmake:112:
Parse error. Function missing ending ")". End of file reached.
CMake Error: Could not find cmake module file: /usr/share/cmake-3.0/Modules/CMakeDetermineCXXCompiler.cmake
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER_ENV_VAR
CMake Error: Could not find cmake module file: /home/pi/Downloads/opencv-3.0.0/release/CMakeFiles/3.0.2/CMakeCXXCompiler.cmake
CMake Error: Error in cmake code at
/usr/share/cmake-3.0/Modules/CMakeDetermineCCompiler.cmake:119:
Parse error. Expected a command name, got unquoted argument with text "".
CMake Error: Could not find cmake module file: /usr/share/cmake-3.0/Modules/CMakeDetermineCCompiler.cmake
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_C_COMPILER_ENV_VAR
CMake Error: Could not find cmake module file: /home/pi/Downloads/opencv-3.0.0/release/CMakeFiles/3.0.2/CMakeCCompiler.cmake
CMake Error: Error in cmake code at
/usr/share/cmake-3.0/Modules/CMakeCXXInformation.cmake:221:
Parse error. Function missing ending ")". End of file reached.
CMake Error: Could not process cmake module file: /usr/share/cmake-3.0/Modules/CMakeCXXInformation.cmake
-- Check for working CXX compiler: /usr/bin/c++
CMake Error at /usr/share/cmake-3.0/Modules/CMakeTestCXXCompiler.cmake:40 (try_compile):
Unknown extension ".cxx" for file
/home/pi/Downloads/opencv-3.0.0/release/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
try_compile() works only for enabled languages. Currently these are:
C CXX
See project() command to enable other languages.
Call Stack (most recent call first):
CMakeLists.txt:88 (project)
-- Check for working CXX compiler: /usr/bin/c++ -- broken
CMake Error at /usr/share/cmake-3.0/Modules/CMakeTestCXXCompiler.cmake:54 (message):
The C++ compiler "/usr/bin/c++" is not able to compile a simple test
program.
It fails with the following output:
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:88 (project)
CMake Error: Error in cmake code at
/usr/share/cmake-3.0/Modules/CMakeCInformation.cmake:113:
Parse error. Function missing ending ")". End of file reached.
CMake Error: Could not process cmake module file: /usr/share/cmake-3.0/Modules/CMakeCInformation.cmake
-- Configuring incomplete, errors occurred!
See also "/home/pi/Downloads/opencv-3.0.0/release/CMakeFiles/CMakeOutput.log".
See also "/home/pi/Downloads/opencv-3.0.0/release/CMakeFiles/CMakeError.log".
Any suggestions?
It's not actually a solution, but I reinstalled my Raspberry Pi again, but this time with the older Raspbian version "Wheezy". On Wheezy, everything worked fine. So I guess there's a problem with Raspbian "Jessie" with OpenCV and/or cmake.