I started a fresh c++ project trying to use boost program_options. Unfortunately I have trouble with cmake; depending on what I try I either get a gmake error not beeing able to build a file or another one about target patterns not containing %.
Actual errors are:
While using ${Boost_LIBRARIES} (case 1): gmake error: No rule to build /usr/local/lib/libbooost_program_options.so
While using Boost::program_options (case 2): gmake error: Target pattern does not conaint "%". Stop.
I sourced my solution attempts from this SO thread: How to link C++ program with Boost using CMake
About case 1: this provides a step by step guide for this problem. Unfortunately after step one "check if the file exists" there is no hint at what to do if it DOES exists, which it does in my case.
stat /usr/local/lib/libboost_program_options.so
Datei: /usr/local/lib/libboost_program_options.so -> libboost_program_options.so.1.62.0
Other threads, such as "No rule to make target" error in cmake when linking to shared library suggest using finder scripts, which I already do.
edit: Thanks to a comment it turned out i was blind for parts of the error message: The path plugged into the makefile is "Boost::program_options-NOTFOUND" which will obviously result in an error.
About case 2: Target pattern contains no '%'. Makefile implies that it is a path problem with any of my paths. I have zero idea how to further debug the problem, as debugging cmake scripts seems to be not well supported. Info on this is hard to find on any search engine.
The two versions of cmake scripts I used look like this:
cmake_minimum_required(VERSION 3.13)
project(probsim)
set(CMAKE_CXX_STANDARD 17)
FIND_PACKAGE(Boost COMPONENTS program_options REQUIRED )
add_executable(probsim main.cpp)
target_link_libraries(probsim ${Boost_LIBRARIES})
# alternative: target_link_libraries(probsim Boost::program_options)
Results are:
-- Boost version: 1.62.0
-- Found the following Boost libraries:
-- program_options
-- Configuring done
-- Generating done
-- Build files have been written to: /home/ketzu/CLionProjects/probsim/cmake-build-debug
Summary: Cmake creates an invalid makefile one way or another, the reason seems to be related to paths used on my filesystem.
While I could find clues for the reasons of the problem, I could not solve them. It was most likely a problem with my system config on fedora.
But as an alternative solution to operating system development library management and troubles with ld I used conan.io with cmake to setup my development environment.
While this might not help everyone sumbling accross similar problems to mine, it might help some out.
Thanks everyone for the help.
Related
I'm trying to run the code in CLion that worked perfectly in Visual Studio. The program has an external dependency - OpenCV 4.2.0 library. I've never worked wtih CMake before so i searched for the solution on how to link the library to the project. I am using MingW-w64 as my environment. CMake builds without a single warning, but when compiling the project it throws an error "undefined reference to (put whatever function from OpenCV here). I spent 5 hours trying to understand what's wrong, looking for solution on forums and, of course, here, but i've failed to find the root of the problem. I created another project just to simplify debugging. Both of the projects throw the same errors with the same CMakeLists.txt files.
Here is my CMakeList.txt:
project(SOMETHINF)
set(CMAKE_CXX_STANDARD 20)
set(OpenCV_DIR "E:\\LIBS\\opencv\\build\\x64\\vc15\\lib")
find_package( OpenCV REQUIRED )
include_directories(${OpenCV_INCLUDE_DIRS})
message(${OpenCV_LIBS})
add_executable(SOMETHINF main.cpp)
target_link_libraries(SOMETHINF ${OpenCV_LIBS})
As you can see i put message() in there to see if it finds the files and it does:
opencv_calib3dopencv_coreopencv_dnnopencv_features2dopencv_flannopencv_gapiopencv_highguiopencv_imgcodecsopencv_imgprocopencv_mlopencv_objdetectopencv_photoopencv_stitchingopencv_videoopencv_videoioopencv_world
-- Configuring done
-- Generating done
-- Build files have been written to: E:/SOMETHINF/cmake-build-debug
[Finished]
Here is the code (there's other unnecessary stuff just because):
And what i get trying to compile it:
Has anyone faced something similar before?
Looks like you are using msvc libraries, but if you use MinGW compiler it will not work.
You can read this link to understand why.
Providing the right libraries should fix your problem ! Usually the owner of the project provide msvc 12/14/15/16 and mingw binaries. If you don't have them I found this unofficial build with a quick search.
I want to use uWebSockets(UWS) in my C++ project to transfer images over the network. The setup will be running on multiple operating systems, so the best way of creating the build files seemed like using CMake.
However, I am new to CMake and having a hard time building UWS. I don't understand how to start working with the official repository on Windows 10, so I found another repository that includes a CMakeFiles.txt file and some of the dependencies (openssl, zlib, libuv, but it doesn't include uSockets for some reason). The root CMakeFiles.txt includes:
[...]
find_package(OpenSSL REQUIRED)
find_package(ZLIB REQUIRED)
find_path(LIBUV_INCLUDE_DIR uv.h)
find_library(LIBUV_LIBRARY NAMES uv uv1)
[...]
It looks straightforward, but when I try to run mkdir build && cd build; cmake .., it cannot find OpenSSL. Here is the error message it spits out:
[...]
[cmake] Could not find a package configuration file provided by "OpenSSL" with any
[cmake] of the following names:
[cmake]
[cmake] OpenSSLConfig.cmake
[cmake] openssl-config.cmake
[...]
The above error message suggests that I need to set up a config file for each of these libraries. Yet, if I understand the find_package docs correctly, the command itself searches the library in various locations under the root folder. What kind of a folder structure does the find_package need in order to work?
More generally, am I wasting my time with this alternative repo? Is there a better way of using UWS with Windows 10? The official repo has a question about how to use it on Windows but I don't understand how that's an answer to the question. It only points to this page where it says any specific build systems will not officially be supported.
Any help would be appreciated.
Importing dependencies with add_subdirectory seems like a good way around this. When I ran cmake, I was receiving LNK2019 Error. I realized the following code snippet I found online was causing the problem, and the system works when I delete it.
if(MSVC)
set(CMAKE_EXE_LINKER_FLAGS_DEBUG "${CMAKE_EXE_LINKER_FLAGS_DEBUG} /NODEFAULTLIB:libcmt.lib /NODEFAULTLIB:msvcrt.lib")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} /SUBSYSTEM:WINDOWS")
endif()
This is going to be a little long of an introduction, but I think it i neccessary for you to understand what I've already tried.
I am currently trying to set up a gRPC Client with C++, after i already set up a Server and Client in Python with no problem. However for C++ the building of gRPC is just evil. With the resources form the offivial git repository I was able to build gRPC (or so i thought) but when I then tried to build my project with Cmake i got an error that the gRPCTargets.cmake is missing. Tracing this back I found that I had to build gRPC itself with all the dependencies as packages instead of submodules. So I started by downloading C-Ares and building it. No Problem here. Next I tried reconfiguring gRPC with the new c-ares directory variable set and type package set. Now i encountered a Problem that the in c-ares-config.cmake an include directory is specified which does not exist at all.
get_filename_component(PACKAGE_PREFIX_DIR "${CMAKE_CURRENT_LIST_DIR}/../../../" ABSOLUTE)
macro(set_and_check _var _file)
set(${_var} "${_file}")
if(NOT EXISTS "${_file}")
message(FATAL_ERROR "File or directory ${_file} referenced by variable ${_var} does not exist !")
endif()
endmacro()
set_and_check(c-ares_INCLUDE_DIR "${PACKAGE_PREFIX_DIR}/include")
include("${CMAKE_CURRENT_LIST_DIR}/c-ares-targets.cmake")
For me the Path with /../../../ doesn't make any sense but since it's automatically generated and I am pretty much a noob using Cmake I cannot say what would be correct there. All i know is that there is no folder named include inside any of the c-ares folders. I tried removing the set_and_check(...) line, which removes the error, but now I am asked for a c-ares-targets.cmake which cannot be found.
I am pretty much stuck here. I would highly appreciate any help or ideas fixing this.
Maybe there is an option of getting a precompiled gRPC-resource for C++ on windows, but was unable to find any sources.
It has been years since I worked in C++, and I've never used CMake before. I'm trying to compile a program called ngmlr, which uses CMake. It worked seamlessly on other systems I tried to build it on. This time around, CMake finds ZLIB (Found ZLIB: /usr/lib64/libz.so (found version "1.2.3")), as required by ngmlr, but the subsequent make fails with ld: cannot find -lz.
I think I know what's happening: CMake found the dynamic ZLIB library (libz.so), but the CMakeLists.txt file requires static (I found the following option in the file: option(STATIC "Build static binary" ON)). As far as I can tell, the static library (libz.a) is missing on this machine. It's not in the same /usr/lib64 directory as libz.so. locate is not available.
Questions:
Does that seem correct?
For education, assuming this is the problem, can you force CMake to look specifically for static ZLIB? e.g., since the developer required static, it would have been nice to immediately know the missing static library was the problem, rather than the embarrassingly long amount of time it took me to figure it out.
I've looked extensively for a clear answer to both, but didn't find anything conclusive (e.g., Force cmake to use static libraries).
UPDATE
I did confirm that the problem is that ld could not find the static library. Now I'm particularly interested to know if the developer can tell CMake to throw an error if the static libraries are not present, and save someone else.
cmake version 2.8.8
Yes
Generally speaking it is up to Find-module authors. Some modules have special "static" option, others do not. Particularly Zlib module has not. That's why cmake global variable is set in subdirectory src/CMakeLists.txt: SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a"). But it is invoked after find_package( ZLIB REQUIRED ) command. Looks like a bug.
Now I'm particularly interested to know if the developer can tell CMake to throw an error if the static libraries are not present, and save someone else.
REQUIRED means that error will be thrown if package was not found. In your case it should be thrown if you move SET(CMAKE_FIND_LIBRARY_SUFFIXES before find_package
Perhaps you can build your project if disable STATIC option
cmake -G"Unix Makefiles" _PATH_ -DSTATIC=OFF
I'm no cmake expert, but in case this helps anyone. I had found setting CMAKE_FIND_LIBRARY_SUFFIXES successfully loaded the static lib, but I only wanted this for finding ZLIB, so I saved the previous value, set CMAKE_FIND_LIBRARY_SUFFIXES and reset it like so:
set(_CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_FIND_LIBRARY_SUFFIXES})
set(CMAKE_FIND_LIBRARY_SUFFIXES "static.lib")
find_package(ZLIB ${ZLIB_VERSION} REQUIRED MODULE)
set(CMAKE_FIND_LIBRARY_SUFFIXES ${_CMAKE_FIND_LIBRARY_SUFFIXES})
unset(_CMAKE_FIND_LIBRARY_SUFFIXES)
Your CMakeLists.txt probably has this somewhere:
find_library(ZLIB z)
You can replace it with:
find_library(ZLIB libz.a)
I am trying to set up Openscenegraph 3.0.1 with Cmake. I read different blog posts but it doesn't work.
I set up the paths, click compile and selected VS11 (because I have VS 2012) and use native compiler.
Then I directly get this error:
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules CMakeCInformation.cmake:37 (get_filename_component):
get_filename_component called with incorrect number of arguments
Call Stack (most recent call first):
CMakeLists.txt:3 (PROJECT)
CMake Error: Internal CMake error, TryCompile configure of cmake failed
Looking for include file pthread.h - not found
Also, more errors with the same stack trace occur. Also also could paste them here if you wish.
Afterwards, CMake tells me "Error in configuration process, project files may be invalid"
your problem isn't in compiler version that you are using; in fact, i'm running OpenSceneGraph 3(and osgEarth) with no problems on VisualStudio 2012.
What it seems to be is a problem with Cmake/CMakeLists.txt itself. Try to build some other projects using cmake, to see whether they work, or try to use a version of CMake that is close to what OpenSceneGraph needs(look at CMAKE_MINIMUM_REQUIRED in main CMakeLists.txt file), although CMake language is meant to be compatible with earlier versions, i dont know if this is always the case.
pthread.h has nothing to do with your problem, DOESN'T EXIST in Windows(except if you are using MinGW to look for some more problems), and is not required by OSG - i think, you configured OpenThreads correctly to not use libs you don't have. Anyway, that's just part of the job CMake does on each build - looks for some random stuff, like whether it can find pthreads.h or not, that give CMake some idea about your environment and don't usually relate to the projects you build with cmake. So just ignore that line about pthread.h
Under normal circumstances, CMake shouldn't be looking for pthread for Windows. Following is the couple of lines in CMake's (2.8) FindThreads.cmake which is used for searching appropriate modules.
...
CHECK_INCLUDE_FILES("pthread.h" CMAKE_HAVE_PTHREAD_H)
if(CMAKE_HAVE_PTHREAD_H)
...
endif()
...
if(CMAKE_SYSTEM MATCHES "Windows")
set(CMAKE_USE_WIN32_THREADS_INIT 1)
set(Threads_FOUND TRUE)
endif()
As you can see, first check should fail and roll out till the second check. However, I believe that in your case, CMake somehow finds that pthread.h (maybe you have MinGW as well) This seems to be a simple conflict in your system. Check your system's PATH etc. and try to fix it.