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.
Related
I am a newbie with CMake please bear with me. I have a library (libvpop) which I created in c++ using some Boost components (system and date_time). I can link to it without a problem in windows but on Ubuntu, I am getting an error that implies the path to the boost include files cannot be found. Here is the simple CMakeLists.txt file.
cmake_minimum_required(VERSION 3.0.0)
set (Boost_DEBUG 1)
project(vpoplibuser)
find_package(fmt CONFIG REQUIRED)
find_package(Boost CONFIG REQUIRED system )
find_package(Boost CONFIG REQUIRED date_time)
add_executable(vpoplibuser vpoplibuser.cpp vpoplib.h)
find_library(VPLIB libvpop HINTS ~/projects/vpoplibuser/ )
message(STATUS "VPLib include dir: ${VPLIB}")
target_include_directories(vpoplibuser PUBLIC ${PROJECT_SOURCE_DIR} )
target_link_libraries(vpoplibuser PUBLIC ${VPLIB})
target_link_libraries(vpoplibuser PRIVATE fmt::fmt)
target_link_libraries(vpoplibuser PRIVATE Boost::system Boost::date_time)
When I run CMake, I get message:
CMake Error in CMakeLists.txt
Imported target "Boost::system" includes non-existent path "/include"
in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
The path was deleted, renamed, or moved to another location.
An install or uninstall procedure did not complete successfully.
The installation package was faulty and references files it does not provide.
I have removed and reinstalled Boost. My Boost libraries are at /lib/x86_64-linux-gnu. I cannot figure out exactly where CMake is searching for the boost include file. When I inspect the _BOOST_INCLUDEDIR variable in boost_header-1.71.0/boost_headers-config.cmake it tells me _BOOST_INCLUDEDIR is "/include". I have read something about the PATH variable being an issue so I added /usr to the beginning of my PATH (there is a folder /usr/include/boost which has the boost .hpp files so I was making an assumption that is what CMake is looking for). I have been stuck on this for a couple of days so I would appreciate any advice from the expert community.
I have found a work around thanks to this article: https://github.com/VowpalWabbit/vowpal_wabbit/issues/3003
Something in the Boost cmake process is causing boost to look for the include files at /include when they are really at /usr/include. I created a symbolic link for /include to point to /usr/include and this allowed cmake to find everything. I have not solved the root cause but can move forward with this approach.
I added the xgboost library as a git submodule of my project and I'm trying to add it to cmake as a subdirectory. Unfortunately it's not working. A simple hello world project with the following CMakeLists.txt replicates the error that I'm getting.
cmake_minimum_required(VERSION 3.2)
project(foo)
add_subdirectory(xgboost)
add_executable(${PROJECT_NAME} foo.cpp)
target_link_libraries(${PROJECT_NAME} xgboost)
After building the library there is nothing in the xgboost/lib directory so I get the following error.
clang: error: no such file or directory:
'/Users/.../myproject/xgboost/lib/libxgboost.dylib'
I think that the problem is generated in their CMakeLists file since they have two different targets. Maybe cmake is choosing the wrong target but I'm not familiar enough with cmake to figure it out. The following code is from xgboost's CMakeLists.
# Executable
add_executable(runxgboost $<TARGET_OBJECTS:objxgboost> src/cli_main.cc)
set_target_properties(runxgboost PROPERTIES
OUTPUT_NAME xgboost
)
set_output_directory(runxgboost ${PROJECT_SOURCE_DIR})
target_link_libraries(runxgboost ${LINK_LIBRARIES})
# Shared library
add_library(xgboost SHARED $<TARGET_OBJECTS:objxgboost>)
target_link_libraries(xgboost ${LINK_LIBRARIES})
set_output_directory(xgboost ${PROJECT_SOURCE_DIR}/lib)
#Ensure these two targets do not build simultaneously, as they produce outputs with conflicting names
add_dependencies(xgboost runxgboost)
My questions in order of importance are:
Is there any way to fix it without modifying xgboost's CMakeLists.txt file?
Is it reasonable to try to add xgboost to my project as a git submodule?
Is there any reason cmake is not instructing to build the library?
Note: There were several edits to this question since I tried to narrow down the problem and to provide more information.
(I would love to ask for few things beforehand in the comment section, but I have too low reputation to do so, so I will just give it a shot ;))
I have few suspects, and one of them is ${CMAKE_SOURCE_DIR} of the submodule's root CMakeLists.txt. Although the paths are set properly when you run that CMakeLists.txt alone, cmake gets confused the moment you add it as your subdirectory. Have you looked into another directories for your output binaries?
First I would suggest testing this hypothesis, and then I would suggest writing similar, but separate CMakeLists.txt file for xgboost library, and then substitute it in the project temporarily. Unfortunately the CMakeLists.txt filename is hardcoded and there is no possibility to have two files of that kind in one directory; so it seems that the answer to 1) is, that you rather have to change the file.
For the 2): as long as it does not require huge additional logic in your CMakeLists.txt, it makes sense. Other viable option is to create an install target, which you can use to install your xgboost library locally (using CMAKE_INSTALL_PREFIX(doc) variable), and then add the installation path to your CMAKE_LIBRARY_PATH(doc).
I have been unable to figure out how to get CMake to find and set correct GLFW CMake constants when using CMake in VS2017. Any help will be greatly appreciated :).
I downloaded glfw3 through Microsoft's vcpkg tool. I have checked that files do physically exist in the directory that vcpkg puts them in (~\vcpkg\installed\x86-windows\include). I set up my CMakeSettings.json as per their docs here. I used that tutorial as a basis for getting GLFW to be set up correctly.
I then use find_package(glfw3 REQUIRED) to find the glfw3 library. This does not spit out any errors. Actually the CMakeLists.txt doesn't complain at all. It's at the compile stage where it complains.
After that I add glfw3 with target_link_libraries(exe ${GLFW3_LIBRARIES}) to the executable.
Then when I try and build a simple example (including the header file), the compilation fails because it cannot find GLFW/glfw3.h.
The error from MSVC:
fatal error C1083: Cannot open include file: 'GLFW/glfw3.h': No such file or directory
Here is my CMakeLists.txt for added reference:
cmake_minimum_required(VERSION 3.7)
project(learn-opengl)
find_package(glfw3 REQUIRED)
add_executable(learn-opengl main.cpp)
target_link_libraries(learn-opengl ${GLFW3_LIBRARIES})
GLFW3_LIBRARIES I got from glfw3Config.cmake by snooping around what vcpkg puts in the installed directory (~\vcpkg\installed\x86-windows\share\glfw3)
And just in case, the main.cpp:
#include <GLFW/glfw3.h>
int main()
{
return 0;
}
I have tried calling cmake from the command line as well, but to no avail that didn't work either.
Am I missing something? Did I perhaps misunderstand something in vcpkg documentation? I have really no idea what I am missing... :/ I should say, in addition, that I am fairly new to CMake as well.
Reformulating my previous comment as answer:
You should add the imported target glfw to your target_link_libraries command instead of ${GLFW3_LIBRARIES}.
The find_package(glfw3) generates an import target glfw. By making your target learn-opengl dependent on this imported target you specify both the library to link with and the include directories to use.
I am new to CMake and DBus. I am following along the guide here and make a basic program compile and execute.
The first problem that I ran into was my program will not find
<dbus/dbus.h>
I got around that issue by adding some include directories to my CMakeList.txt.
Currently, my CMakeLists.txt looks like this:
...
include_directories(/usr/lib/)
include_directories(/usr/include/dbus-1.0/)
include_directories(/usr/lib/x86_64-linux-gnu/dbus-1.0/include)
include_directories(/usr/include/glib-2.0)
include_directories(/usr/lib/x86_64-linux-gnu/glib-2.0/include/)
set (LIBS
dbus-1
dbus-glib-1
)
add_executable(mydbus mydbus.cpp)
target_link_libraries(mydbus ${LIBS} )
Now, my program is complaining about not being able to find dbus-arch-deps.h
/usr/include/dbus-1.0/dbus/dbus.h:29:33: fatal error: dbus/dbus-arch-deps.h: No such file or directory
#include <dbus/dbus-arch-deps.h>
I know that the solution for this is to use proper command line flags or pkg-config. As discussed here and numerous other posts.
However, I do not know how to configure CMakeLists.txt to have similar effect.
My guess would be to add something like find_package(dbus-1) to CMakeLists.txt. And if that is correct, I am going to have to write my own Finddbus-1.cmake. Does this sound correct? Or is there an easier way?
I will appreciate any pointers.
You may get an existing FindDBus.cmake script (e.g., this one), copy it into your project, and use as
find_package(DBus REQUIRED)
# Use results of find_package() call.
include_directories(${DBUS_INCLUDE_DIRS})
add_executable(mydbus mydbus.cpp)
target_link_libraries(mydbus ${DBUS_LIBRARIES})
Alternatively, as you know pkgconfig can find DBus, you may use CMake module PkgConfig. Actually, FindDBus.cmake script, referenced above, uses PkgConfig module in its implementation. Possible usage could be:
find_package(PkgConfig REQUIRED) # Include functions provided by PkgConfig module.
pkg_check_modules(DBUS REQUIRED dbus-1) # This calls pkgconfig with appropriate arguments
# Use results of pkg_check_modules() call.
include_directories(${DBUS_INCLUDE_DIRS})
link_directories(${DBUS_LIBRARY_DIRS})
add_executable(mydbus mydbus.cpp)
target_link_libraries(mydbus ${DBUS_LIBRARIES})
However, using link_directories is not recommended, it is better to use absolute paths to libraries in target_link_libraries() call. That is why it is better to combine pkg_check_modules with find_library, as it is done in the referenced Find script. That answer describes generic way for use result of pkgconfig in CMake.
I Ubuntu, I am learning about cmake and make, and just trying a simple example. I have two directories: src and build. In src, I have two files: main.cpp, and CMakeLists.txt, which has (only) the following text:
add_executable(test main.cpp)
link_directories(/usr/lib/x86_64-linux-gnu)
target_link_libraries(test protobuf)
In /usr/lib/x86_64-linux-gnu, there is a shared library called libprotobuf.so, which I want to link against. My main.cpp uses functions in this library, by including the releveant header file, #include <google/protobuf/message.h>.
Now, in my build directory, I run cmake ../src, and then make. However, I then get linker errors telling me that there are undefined references to some of the functions in the protobuf library. If I do a search through all the files and subdirectories in build, there is not mention of anything related to protobuf.
However, if I remove the link_directories line in my CMakeLists.txt file, and instead write the full path to the library when specifying the executable, i.e. target_link_libraries(test /usr/lib/x86_64-linux-gnu/libprotobuf.so), it compiles and links fine.
Why is link_directories not allowing cmake to find this library?
Do not use link_directories like this in CMake.
This is a common beginner's mistake, as many other build environments work like this, but in CMake it's just asking for trouble. Even the official documentation specifically advises against it:
Note that this command [link_directories] is rarely necessary. Library locations returned
by find_package() and find_library() are absolute paths. Pass these
absolute library file paths directly to the target_link_libraries()
command. CMake will ensure the linker finds them.
So instead, always pass absolute paths to target_link_libraries and use find_library to resolve the link directory:
find_library(PROTOBUF_LIBRARY protobuf HINTS /usr/lib/x86_64-linux-gnu)
target_link_libraries(test PUBLIC ${PROTOBUF_LIBRARY})
This has the huge benefit that you will probably get a diagnostic at CMake configure time if the expected library cannot be found, instead of a random linker error at compile time. Also, this allows the user to specify a library location via the GUI if the target machine has a non-standard directory layout.
So if it doesn't work right away, be sure to check the result of the find_library call and consult the official documentation to track down why it doesn't find your library as intended.
Make sure that your call to link_directories takes place before your call to the relevant add_executable.
I had mistakenly believed it only needed to be before the call to target_link_libraries, but that's not the case. After moving the call, the library is linked properly.
Make sure that the order will be link_directories, set PROJECT_LINK_LIBS, add_executable and then target_link_libraries.
Below is example to demonstarte it:
cmake_minimum_required(VERSION 2.8.9)
project (Logging)
include_directories(include)
file(GLOB LOGGINGSOURCES "libsrc/*.cpp")
file(GLOB SOURCES "src/*.cpp")
add_library(convertString SHARED ${LOGGINGSOURCES})
install(TARGETS convertString DESTINATION /root/Deepak/)
link_directories( /root/Deepak/ )
set(PROJECT_LINK_LIBS libconvertString.so)
add_executable(hello ${SOURCES})
target_link_libraries(hello ${PROJECT_LINK_LIBS} )
Perhaps it's very old topic but none of proposed solutions worked for me. So I had to make my own dirty hack. I do crosscompiling with buildroot and include toolchainfile.cmake.
#...
set(LIB_PATH ${PROJECT_SOURCE_DIR}/relative/path/to/your/lib)
#...
include_directories(/path/to/library/include)
set(LIB_MYLIB ${LIB_PATH}/libmylib.so)
#...
add_executable(${PROJECT_NAME} ${APP_SOURCES})
target_link_libraries(${PROJECT_NAME}
${LIB_MYLIB}
)
Hope this will help