Okay I have a project in CMake structured like this:
CMakeLists.txt
/libfoo/CMakeLists.txt
/frontend/qt/CMakeLists.txt
libfoo is a library I'm writing and frontend/qt is a small frontend and also an example of usage. The problem is that CMake passes the relative path to libfoo.so.x to the linker instead of an -l option. The Qt gui target is declared like this:
add_executable(qtgui ${qtgui_sources} ${qtgui_moced} ${qtgui_ui_h})
target_link_libraries(qtgui ${QT_LIBRARIES} foo)
I'd rather it just linked againts -lfoo like all other libs, not the full path.
How to do that?
Thank you!
Ah, never mind, found it:
http://www.cmake.org/Wiki/CMake_RPATH_handling
I obviously didn't google enough, sorry.
Related
I have recently installed CMake in order to write code to make use of Libbitcoin in C++ but I am having a hard time, I was trying to build the example code on GitHub here. And it haters been going terribly. I can't manage to link the library right in CMake, here is my code. I read and people were saying that I should try Autoconf but I have no idea how to even start that as I know nothing about Autoconf. I have CMake 3.16, and installed Libbitcoin with brew but alias were made in /usr/local/include for the library, I am on Mac OS X 10.15. The CMake runs fine but when running "make", it responds with:
Scanning dependencies of target CreateAddr
main.cxx:1:10: fatal error: bitcoin/bitcoin.hpp: No such file or directory
1 | #include <bitcoin/bitcoin.hpp>
| ^~~~~~~~~~~~~~~~~~~~~
Here is my CMake text:
Please all help is appreciated I am beyond lost.
It is hard to be sure without knowing the specifics of your installation, but it appears that your include directory paths may be overlapping with what is specified for the header in main.cxx. The include_directories() call tells the compiler to include headers from this directory:
/usr/local/include/bitcoin
Then, in main.cxx, you're including the file with bitcoin/bitcoin.hpp. Combining these suggests the file is located here:
/usr/local/include/bitcoin/bitcoin/bitcoin.hpp
The error states the header could not be found, so perhaps you meant to locate it here:
/usr/local/include/bitcoin/bitcoin.hpp
In that case, just remove the relative directory path from the main.cxx file, like this:
#include <bitcoin.hpp>
Also, you want to link to your libbitcoin library correctly. Using link_directories() is not recommended. Instead, you can specify the full path to your libbitcoin library directly in the call to target_link_libraries(). The library may not be located in /usr/local/include/bitcoin. With these changes, the last few lines in your CMake would look something more like this:
include_directories(/usr/local/include/bitcoin)
add_executable(CreateAddr main.cxx)
target_link_libraries(CreateAddr PUBLIC /your/path/to/libs/libbitcoin.so)
I have build libmemcached.a and copied it to /usr/local/lib on my mac and I have tried all the following options to link libmemcached.a and yet get compile time errors that libmemcached/memcached.h is not found.
link_libraries (${libmemcached})
include_directories(SYSTEM ${libmemcached})
link_directories("/usr/local/lib")
find_package(libmemcached.a REQUIRED)
link_libraries`enter code here`(libmemcached.a)
find_library(RESULT libmemcached.a PATHS /usr/local/lib)
target_link_libraries(dnsa_pcl libmemcached.a)
It is a simple -L -l using MakeFile. Not sure what needs to be done to make this work using CMakeLists. Any help is much appreciated.
you should use so called imported library, like it's described in the official documentation
The solution that worked for me is a bit weird. I had to both set the CMAKE_PREFIX_PATH to the directory that has the lib and also have include_directories() with the include folder of the source. For some reason, I was under the impression that the libmemcached.a had the header files as well.
One of my executables requires libgfortran.so. Typically I'd just add the -lgfortran switch to the compile line and it links automatically with g++. However, I'm trying to find the library with CMAKE using:
find_library(GFORTRAN_LIBRARY NAMES gfortran)
target_link_libraries(ncorr_test ${GFORTRAN_LIBRARY})
However, this fails to the find the library. It turns out the only way that has worked so far is if I include the entire library name like so:
find_library(GFORTRAN_LIBRARY NAMES libgfortran.so.3)
target_link_libraries(ncorr_test ${GFORTRAN_LIBRARY})
Then, it will link properly:
/usr/bin/c++ ... /usr/lib/x86_64-linux-gnu/libgfortran.so.3 ...
However, including the whole .so.3 is not very portable. Does anyone know of a better way to do this? Typically libraries I need to use are just installed in /usr/local/lib and searching for the library name without the "lib" and extension works (i.e. find_library(FFTW_LIBRARY NAMES fftw3) will find libfftw3.a in /usr/local/lib just fine).
EDIT:
find_library(GFORTRAN_LIBRARY NAMES libgfortran.so) does not work either. Only libgfortran.so.3 has worked so far.
Using locate libgfortran outputs:
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.a
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.so
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortran.spec
/usr/lib/gcc/x86_64-linux-gnu/4.8/libgfortranbegin.a
/usr/lib/x86_64-linux-gnu/libgfortran.so.3
/usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
/usr/local/MATLAB/R2014a/sys/os/glnxa64/libgfortran.so.3
/usr/local/MATLAB/R2014a/sys/os/glnxa64/libgfortran.so.3.0.0
/usr/share/doc/libgfortran-4.8-dev
/usr/share/doc/libgfortran3
/var/lib/dpkg/info/libgfortran-4.8-dev:amd64.list
/var/lib/dpkg/info/libgfortran-4.8-dev:amd64.md5sums
/var/lib/dpkg/info/libgfortran3:amd64.list
/var/lib/dpkg/info/libgfortran3:amd64.md5sums
/var/lib/dpkg/info/libgfortran3:amd64.postinst
/var/lib/dpkg/info/libgfortran3:amd64.postrm
/var/lib/dpkg/info/libgfortran3:amd64.shlibs
/var/lib/dpkg/info/libgfortran3:amd64.symbols
EDIT2:
For now I'll just require the user to copy libgfortran.a over to their usr\local\lib directory
Looks like you either miss dev package on your linux distribution, which should install .so link, or path where such link located is missing when cmake does lookup. Try to find libgfortran.so link, usually it is located the same place where .so.3 is, if you cannot find it install missing dev package, if you can check why that path is not included in cmake.
Why this code does not produce anything?
link_directories(${CMAKE_SOURCE_DIR}/libs/mylib1)
message("DIR: ${LINK_DIRECTORIES}")
I have problem on Windows that though I do link_directories() there is NO -L... flag when linking. I do create target after link_directories command as documentation suggests.
By using "link_directories(${CMAKE_SOURCE_DIR}/libs/mylib1)" you are telling CMake to tell the linker to look for libraries in "${CMAKE_SOURCE_DIR}/libs/mylib1" when it needs to link against a library with a plain name, as in "png" or "zlib".
Using link_directories is not even recommended anymore, however. We always recommend to use target_link_libraries with the full path name to the library files that you want to link to. Then CMake takes care of arranging all the -L and -l arguments to the linker on all the different platforms for you.
Please add more information to your question if you would like more help. It's a bit unclear what you are trying to do, or what you are expecting.
Because LINK_DIRECTORIES is not variable, but a directory property. You can obtain it in such way:
get_directory_property(OUT_VAR LINK_DIRECTORIES)
message(STATUS "DIR: ${OUT_VAR}")
See documentation.
I'm not sure what you are trying to achieve overall.
Would target_link_libraries do a better overall job?
target_link_libraries( TARGET LIB1 LIB2 LIB3 ... )
I am trying to compile one of the projects found here
USB-I2C/SPI/GPIO Interface Adapter.
I downloaded the i2c_bridge-0.0.1-rc2.tgz package. I installed libusb and that seemed to go well with no issues. I go into the i2c_bridge-0.0.1-rc2/ directory and make. That compiles. I move into the i2c_bridge-0.0.1-rc2/i2c folder and make. It compiles and gives me ./i2c. However, when I run it, it says error while loading shared libraries: libi2cbrdg.so: cannot open shared object file: No such file or directory
The makefile in i2c_bridge-0.0.1-rc2/i2c has the library directory as ../. The libi2cbrdg.so is in this directory (i2c_bridge-0.0.1-rc2). I also copied the file to /usr/local/lib. An ls of the i2c_bridge-0.0.1-rc2/ directory is
i2c i2cbrdg.d i2cbrdg.o libi2cbrdg.a Makefile tests
i2cbrdg.c i2cbrdg.h INSTALL libi2cbrdg.so README u2c4all.sh
(That i2c is a directory)
If I sudo ./i2c, it still gives me the problem.
I had to take away the -Werror and -noWdecrepated (spelling?) options in all the makefiles to get them to compile, but that shouldn't affect this should it?
What else is necessary for it to find the .so file? If anyone can help me find out what is wrong I would be very grateful. If more information is needed I can post it.
You have to distinguish between finding so's at compile-time and at run-time. The -L flag you give at compile-time has nothing to do with localizing the library at run-time. This is rather done via a number of variables and some paths embedded in the library.
The best hot-fix for this problem is often setting LD_LIBRARY_PATH to the directory with the .so file, e.g.:
$ LD_LIBRARY_PATH=.. ./i2c
For a long-term solution, you need to either have a close look at the whole LD system with rpath and runpath, or use libtool (which solves these issues for your portably).
Copying a file to /usr/local/lib is often insufficient because ld caches the available libraries, so you need to re-run ldconfig (as root) after you copied a library to /usr/local/lib.
If you are building the code from source that needs the the library, you can put the path that the library is in in the environment variable LD_RUN_PATH before building, and the linker will save that path into the binary, so that it will automatically be looked for in the right place at runtime.
Linux specific: Alternately, put the library in /lib, /usr/lib, or some other path referenced in your /etc/ld.so.conf or its imported config fragments, and then all you need to do is run /sbin/ldconfig to refresh ld.so (the dynamic linker)'s cache of libraries.
This works for my issue,hope will help anyone.
gcc test.c -Wl,-rpath /usr/local/lib -lfcgi -o test.fcg
And -Wl,-rpath option is the key trick.