FindGLEW.cmake No Rule To Make Target Error [SOLVED] - macos

I am trying to build a very simple 'hello triangle' OpenGL application using CMake. I want to use find_package(GLEW) and the resulting imported target to link with Glew. When I run the make command, I am getting a 'No rule to make target' error.
According to the CMake documentation
https://cmake.org/cmake/help/latest/module/FindGLEW.html
https://cmake.org/cmake/help/latest/command/find_package.html
I can use find_package(GLEW) to return a target GLEW::GLEW which I will be able to use to link the Glew library to my code. When I run cmake .. everything builds and it reports that the glew-config.cmake file has been found.
-- Found GLEW: /usr/local/lib/cmake/glew/glew-config.cmake
I then run make and receive this error
$ make
Scanning dependencies of target test
[ 50%] Building CXX object CMakeFiles/test.dir/main.cpp.o
make[2]: *** No rule to make target `/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework', needed by `test'. Stop.'
I am running Mojave 10.14 and used homebrew to install cmake and glew which are both up to date. The path returned in the error above does not exist and I don't know where it is coming from.
Here is my CMakeLists.txt:
cmake_minimum_required(VERSION 3.15)
project(test)
find_package(GLEW REQUIRED)
add_executable(test main.cpp)
target_link_libraries(test GLEW::GLEW)
Here is my source code:
#include <GL/glew.h>
#include <iostream>
int main(int argc, char **argv){
std::cout << "Glew Test" << std::endl;
}
As you can see it is the bare minimum code needed to simply link Glew.
The problem seems to be similar to this question:
CMake FIND_PACKAGE succeeds but returns wrong path
However, in that case there was a solution using a command line flag specific to Boost. The only reference I have found regarding FindGLEW and problems with macOS is here:
https://gitlab.kitware.com/cmake/cmake/issues/19542
But that seems to have been resolved.
The problem I am having seems to be this path that FindGLEW.cmake is returning:
/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework
I have looked in the actual FindGLEW.cmake file to see if I could find the source of this path but I'm not an expert with CMake so got lost pretty quickly. How could I find the origin of this path? Are there any CMake flags or variables I can set to work around this similar to the Boost question above?
I have successfully linked with Glew using this CMakeLists.txt:
cmake_minimum_required(VERSION 3.15)
project(test)
find_library(GLEW_DYLIB GLEW "/usr/local/Cellar/glew/2.1.0/lib")
if(NOT GLEW_DYLIB)
message(FATAL_ERROR "Glew not found")
endif()
add_library(Glew_target SHARED IMPORTED)
set_property(TARGET Glew_target PROPERTY IMPORTED_LOCATION "/usr/local/Cellar/glew/2.1.0/lib/libGLEW.dylib")
set_property(TARGET Glew_target PROPERTY IMPORTED_IMPLIB ${GLEW_DYLIB})
include_directories(
"/usr/local/Cellar/glew/2.1.0/include/"
)
add_executable(test main.cpp)
target_link_libraries(test Glew_target)
However, I would prefer to keep things as simple as possible with find_package() as that is definitely the cleaner method.
EDIT: SOLVED - see Tsyvarev's comment below clarifying the nature of the glew-config file that CMake was finding above. I removed this file and rebuilt the project with no problems.

Related

CMake Error: variable set to NOTFOUND even after defining it manually

I am new to cmake and attempting to build an existing repository that relies on GLEW. I have installed GLEW using Homebrew and am now trying to run cmake . The configuration step completes, but the generation step raises the following error:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
GLEW_LIBRARY
I have checked/tried the following:
CMakeLists.txt contains a line find_package(GLEW REQUIRED) which does not fail. I even added the line FIND_LIBRARY(GLEW_LIBRARY NAMES libGLEW.dylib PATHS /opt/local/lib /usr/local/lib /usr/lib REQUIRED) to explicitly tell cmake where to look for the library and it finds the correct path.
There is a file FindGlew.cmake that was placed in /usr/local/Cellar/cmake/3.25.2/share/cmake/Modules (I assume during the homebrew install of GLEW). It contains a line unset(GLEW_LIBRARY). I'm a bit hesitant to mess with the file (it shouldn't be necessary, right?) but I tried commenting that line out and running cmake again, but it didn't have any effect.
CMakeCache.txt contains the variables GLEW_LIBRARY_DEBUG and GLEW_LIBRARY_RELEASE which were set to GLEW_LIBRARY_DEBUG-NOTFOUND etc. I edited them manually to the path of the libGLEW.dylib file and added an additional path which I called GLEW_LIBRARY, but to no avail.
CMakeCache.txt also contains a variable GLEW_DIR which is defined. There is a GLEW_LIBRARY_DIR which is also NOTFOUND.
I passed the variable as an explicit command using cmake . -DGLEW_LIBRARY=/usr/local/lib/libGLEW.dylib. I tried this both with and without first deleting the cache.
Statically define the library using the approach in this answer.
brew reinstall glew.
I do have OpenGL installed as wel, but built from source (not via Homebrew). Could It have something to do with them not being linked correctly? OpenGL is found properly by CMakeLists.txt, so cmake must have access to its path somehow.
Edit: this is (a MWE of) the CMakeLists.txt file:
cmake_minimum_required (VERSION 3.15)
project ("ProjectName" LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
find_package(OpenGL REQUIRED)
include_directories( ${OPENGL_INCLUDE_DIRS} )
# set(CMAKE_FIND_DEBUG_MODE TRUE)
find_package(GLEW REQUIRED)
# set(CMAKE_FIND_DEBUG_MODE FALSE)
include_directories(${GLEW_INCLUDE_DIRS})
file(GLOB sources CONFIGURE_DEPENDS src/*.cpp src/*.hpp *src/.h)
add_executable(${PROJECT_NAME} ${sources})
target_link_libraries(${PROJECT_NAME} ${OPENGL_LIBRARIES} ${GLEW_LIBRARIES})
file(COPY ${RESOURCE_FILES} DESTINATION ${CMAKE_BINARY_DIR}/Resources)
Edit: for completeness, here is the full output / error message:
-- The CXX compiler identification is AppleClang 14.0.0.14000029
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenGL: /Library/Developer/CommandLineTools/SDKs/MacOSX13.1.sdk/System/Library/Frameworks/OpenGL.framework
-- Found GLEW: /usr/local/lib/cmake/glew/glew-config.cmake
-- Configuring done
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
GLEW_LIBRARY
linked by target "ProjectName" in directory /Users/user1/dev/project
-- Generating done
CMake Generate step failed. Build files cannot be regenerated correctly.
EDIT2: According to FindGLEW you should use one of the imported targets - GLEW::GLEW i.e.
target_link_libraries(your_target GLEW::GLEW ... )
I would also kindly ask you to post the new errors that you are getting related to the MRE you posted. I will update my answer accordingly.
EDIT: Because you mentioned that some people can compile it and some people can't. Look at this line right here:
find_package(GLEW CONFIG QUIET)
if(GLEW_FOUND)
#...
This line tries to find the actual GLEWConfig.cmake file to configure this. Meaning that if you've installed the package OR they have in a way that you have this GLEWConfig.cmake file then you will get different results.
My recommendation is: Figure out exactly how they installed their GLEW (or if they compiled it) and recreate the exact same environment.
Here is the link to FindGLEW.cmake. On Lines 41-58 you can see the variables that you can use in your project. There is NO GLEW_LIBRARY.
If you look down in the file you'll see why:
if(GLEW_FOUND)
find_package_handle_standard_args(GLEW DEFAULT_MSG GLEW_CONFIG)
get_target_property(GLEW_INCLUDE_DIRS GLEW::GLEW INTERFACE_INCLUDE_DIRECTORIES)
set(GLEW_INCLUDE_DIR ${GLEW_INCLUDE_DIRS})
get_target_property(_GLEW_DEFS GLEW::GLEW INTERFACE_COMPILE_DEFINITIONS)
if("${_GLEW_DEFS}" MATCHES "GLEW_STATIC")
get_target_property(GLEW_LIBRARY_DEBUG GLEW::GLEW IMPORTED_LOCATION_DEBUG)
get_target_property(GLEW_LIBRARY_RELEASE GLEW::GLEW IMPORTED_LOCATION_RELEASE)
else()
get_target_property(GLEW_LIBRARY_DEBUG GLEW::GLEW IMPORTED_IMPLIB_DEBUG)
get_target_property(GLEW_LIBRARY_RELEASE GLEW::GLEW IMPORTED_IMPLIB_RELEASE)
endif()
get_target_property(_GLEW_LINK_INTERFACE GLEW::GLEW IMPORTED_LINK_INTERFACE_LIBRARIES_RELEASE) # same for debug and release
list(APPEND GLEW_LIBRARIES ${_GLEW_LINK_INTERFACE})
list(APPEND GLEW_LIBRARY ${_GLEW_LINK_INTERFACE})
select_library_configurations(GLEW)
if("${_GLEW_DEFS}" MATCHES "GLEW_STATIC")
set(GLEW_STATIC_LIBRARIES ${GLEW_LIBRARIES})
else()
set(GLEW_SHARED_LIBRARIES ${GLEW_LIBRARIES})
endif()
unset(_GLEW_DEFS)
unset(_GLEW_LINK_INTERFACE)
unset(GLEW_LIBRARY) #<-- here the temporary variable is unset
unset(GLEW_LIBRARY_DEBUG)
unset(GLEW_LIBRARY_RELEASE)
return()
endif()
GLEW_LIBRARY is a temporary variable used to set other variables.
What instead you want to use is: GLEW_LIBRARIES

CLion and CMake Doesn't Complain but Failed to build OpenCV

Summary
In Windows, CLion doesn't complain anything after cmake and before makefile.
All code seems to link correctly without error. I am able to see the reference, documents, linter and jump into cv::Mat or opencv.hpp header file with ctrl RMB.
CMake seems to correctly generate make files without error.
But the compile error occurs: undefined reference to OpenCV methods.
my setup
CMakeLists.txt:
cmake_minimum_required(VERSION 3.9)
project(test)
# Set compile version
set(CMAKE_CXX_STANDARD 17)
add_executable(test ./test.cpp )
find_package(OpenCV REQUIRED)
message(STATUS "OpenCV library status:")
message(STATUS " version: ${OpenCV_VERSION}")
message(STATUS " libraries: ${OpenCV_LIBS}")
message(STATUS " libraries: ${OpenCV_LIBRARIES}")
message(STATUS " include path: ${OpenCV_INCLUDE_DIRS}")
target_link_libraries(test ${OpenCV_LIBRARIES})
The output seems correct
"D:\Program Files\JetBrains\CLion 2021.3.2\bin\cmake\win\bin\cmake.exe" -DCMAKE_BUILD_TYPE=Debug -G "CodeBlocks - MinGW Makefiles" D:\repo\CS5330\test
-- OpenCV library status:
-- version: 4.5.5
-- libraries: opencv_calib3d;opencv_core;opencv_dnn;opencv_features2d;opencv_flann;opencv_gapi;opencv_highgui;opencv_imgcodecs;opencv_imgproc;opencv_ml;opencv_objdetect;opencv_photo;opencv_stitching;opencv_video;opencv_videoio;opencv_world
-- libraries: opencv_calib3d;opencv_core;opencv_dnn;opencv_features2d;opencv_flann;opencv_gapi;opencv_highgui;opencv_imgcodecs;opencv_imgproc;opencv_ml;opencv_objdetect;opencv_photo;opencv_stitching;opencv_video;opencv_videoio;opencv_world
-- include path: /path/to/scoop/apps/opencv/current/include
-- Configuring done
-- Generating done
-- Build files have been written to: /path/to/test/cmake-build-debug
[Finished]
And this generates CMakeCache.txt, which includes,
//The directory containing a CMake configuration file for OpenCV.
OpenCV_DIR:PATH= /path/to/scoop/apps/opencv/current/x64/vc15/lib
//Details about finding OpenCV
FIND_PACKAGE_MESSAGE_DETAILS_OpenCV:INTERNAL=[/path/to/scoop/apps/opencv/current][v4.5.5()]
As you see, system-wide environment variable OpenCV_DIR has been already set and read correctly by CLion.
Here is a simple test code, but failed to run
#include <opencv2/opencv.hpp>
int main() {
cv::Mat img = cv::imread("./test.jpg", -1);
cv::imshow("Mon image", img);
cv::waitKey(0);
return 0;
}
I also installed msys2 from winget, and from msys2 installed clang, make, MinGW-w64 GDB,cmake. Following this tutorial.
And tested through that toolchain instead of CLion bundled toolchain, it returns the same result.
OpenCV binary is from scoop.
For some reason, it has the same problem as one from homebrew. In opencv.hpp, includes headers are incorrect due to file hierarchy that opencv.hpp is inside opencv2 folder.
I changed all #include "opencv2/header.hpp" to #include "header.hpp", but it doesn't help, and vice versa.
Can't figure out the reason for hours.. Any help will be appreciated.

Build with libpqxx in C++11 on Kdevelop

I'm trying to build a C++ program, that needs lipqxx functionalities. I'm on Ubuntu and I'm trying to use Kdevelop.
I did it successfully with Code::Blocks, but I'm trying to find a better IDE.
Now, what I've done with Kdevelop.
I created a simple example:
#include <pqxx/pqxx>
int main(int argc, char **argv) {
pqxx::connection c("dbname=xx host=localhost user=xx password=xx");
return 0;
}
I modified the CmakeList.txt to include the pqxx directory and to link with libpqxx.so:
cmake_minimum_required(VERSION 2.6)
project(testkdev)
include_directories ("/usr/include/pqxx")
LINK_DIRECTORIES("/usr/lib")
add_executable(testkdev main.cpp)
TARGET_LINK_LIBRARIES(testkdev libpqxx.so)
install(TARGETS testkdev RUNTIME DESTINATION bin)
At this point, the build process works.
But I need to do something else, I want to work in C++11.
So I add a -std=c++11 option, right clicking on my project, Open Configuration > Cmake > Advanced Values > CMAKE_CXX_FLAGS.
And I get the following errors:
/home/francis/projects/testKDEV/build> make -j2
[100%] Building CXX object CMakeFiles/testkdev.dir/main.cpp.o
In file included from /usr/include/c++/4.9/memory:79:0,
from /usr/include/c++/4.9/tr1/memory:39,
from /usr/include/pqxx/util.hxx:31,
from /usr/include/pqxx/util:18,
from /usr/include/pqxx/except.hxx:27,
from /usr/include/pqxx/except:19,
from /usr/include/pqxx/result.hxx:33,
from /usr/include/pqxx/result:19,
from /usr/include/pqxx/binarystring.hxx:26,
from /usr/include/pqxx/binarystring:18,
from /usr/include/pqxx/pqxx:17,
from /home/francis/projects/testKDEV/main.cpp:2:
/usr/include/c++/4.9/functional:1034:20: error: expected template-name before ‘<’ token
: tuple_element<__i, _Tuple> { };
^
/usr/include/c++/4.9/functional:1034:20: error: expected ‘{’ before ‘<’ token
/usr/include/c++/4.9/functional:1034:20: error: expected unqualified-id before ‘<’ token
/usr/include/c++/4.9/functional:1054:17: error: ‘tuple_size’ was not declared in this scope
(__i < tuple_size<_Tuple>::value)>
^
/usr/include/c++/4.9/functional:1054:35: error: ‘::value’ has not been declared
(__i < tuple_size<_Tuple>::value)>
and it goes on and on with errors...
Could anybody please help me understanding what I'm doing wrong ?
I don't know Kdevelop but I had similar problem. I use Eclipse. There is my question and answer. That is in Polish, so find someone, who can translate that. My English isn't too good but I'm going to transtalte as well as I can.
My question (forum.dobreprogramy.pl)
You need libpqxx-4.0.1. Download these packages:
md5sum
libpqxx-4.0.1
Next:
check package: md5sum -c libpqxx-4.0.1.tar.gz.md5sum
If it's ok: tar -xzvf libpqxx-4.0.1.tar.gz
cd libpqxx-4.0.1
./configure --prefix=/usr/local --enable-shared
You can choose path other than "/usr/local". There will be installed libpqxx.
make clean
make
make install
Now you should have header files in /usr/local/include and libpqxx.a, libpqxx.so in /usr/local/lib. If everything is ok, link libraries in IDE. I don't know, how to do this in your IDE but this is generally the same but properties are in different places. For example in Eclipse CDT:
In Project/properties/C\C++ Buid/Settings/GCC C++ Compiler/Includes/include paths type: /usr/local/include
In GCC C++ Linker/Libraries/Library search path type: /usr/local/lib
In GCC C++ Linker/Libraries/Libraries type: pqxx
In project: #include
Now try to compile. If it's ok, try to run program. If you have problem like in post #15
error while loading shared libraries: libpqxx-4.0.so: cannot open shared object file: No such file or directory
Go to /etc/ld.so.conf.d/ and make there new file named libpqxx-4.0.1.conf next open the file nad type there /usr/local/lib
After that issue the command ldconfig
In my case it was everything to connect with PostgreSQL using libpqxx and C++11. Good luck.

Boost include headers not found using cmake

This question is very similar to Why is this boost header file not included, however the hints there don't (seem to) solve my problem.
I got a CMakeLists.txt
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(jetorigin)
SET(Boost_ADDITIONAL_VERSIONS "1.43" "1.43.0" "1.44" "1.44.0" "1.45" "1.45.0")
SET(BOOST_ROOT "$ENV{HOME}/usr")
MESSAGE(STATUS "** Search Boost root: ${BOOST_ROOT}")
FIND_PACKAGE(Boost 1.43 COMPONENTS filesystem regex REQUIRED)
MESSAGE(STATUS "** Boost Include: ${Boost_INCLUDE_DIR}")
MESSAGE(STATUS "** Boost Libraries: ${Boost_LIBRARY_DIRS}")
MESSAGE(STATUS "** Boost Libraries: ${Boost_LIBRARIES}")
INCLUDE_DIRECTORIES(${BOOST_INCLUDE_DIR})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
ADD_SUBDIRECTORY(src)
And include some boost headers in my code like this:
#include <boost/regex.hpp>
#include <boost/filesystem.hpp>
#include <boost/filesystem/fstream.hpp>
Now the output from cmake looks ok
-- ** Search Boost root: /home/oli/usr
-- Boost version: 1.43.0
-- Found the following Boost libraries:
-- filesystem
-- regex
-- ** Boost Include: /home/oli/usr/include
-- ** Boost Libraries: /home/oli/usr/lib
-- ** Boost Libraries: /home/oli/usr/lib/libboost_filesystem.so;/home/oli/usr/lib/libboost_regex.so
But I get this error:
error: boost/regex.hpp: No such file or directory
(and similar for the other includes). Full output from make VERBOSE=1 can be found here http://pastebin.ca/2039425. It looks as though there is no -I flag added even though Boost_INCLUDE_DIR seems to be set correctly.
I'm using CMake 2.8.1 by the way.
I would very much appreciate any hints on what is going wrong here..
EDIT:
I've found the problem. Seems I pulled some ancient version of my standard CMakeLists.txt from the depths of my archives. It needs to be:
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIR})
(note the non-capitalized "Boost")...
Maybe older versions of CMake have been more tolerant in this respect or by bad luck I simply chose to start with a version of my CMakeLists.txt with an unfixed bug..
Since you did not specify a mode for find_package, it attempts to first use MODULE mode, and then CONFIG mode. As per the docs for the FindBoost module, the cache variable storing the directory containing Boost headers is named Boost_INCLUDE_DIR and not BOOST_INCLUDE_DIR. As per the CMake language docs' section on variables, CMake variable names are case-sensitive. I don't know why you had another CMakeLists.txt file with BOOST_INCLUDE_DIR working.

Cmake doesn't find Boost

I'm trying to configure a project using CMake, but it fails to find Boost libraries even though they are in the specified folder. I have specified Boost_INCLUDE_DIR, Boost_LIBRARYDIR and BOOST_ROOT , but I still get an error saying that CMake is not able to find Boost. What could be the reason of such error?
Are you sure you are doing it the correct way? The idea is that CMake sets BOOST_INCLUDE_DIR, BOOST_LIBRARYDIR and BOOST_ROOT automatically. Do something like this in CMakeLists.txt:
FIND_PACKAGE(Boost)
IF (Boost_FOUND)
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIR})
ADD_DEFINITIONS( "-DHAS_BOOST" )
ENDIF()
If boost is not installed in a default location and can, thus, not be found by CMake, you can tell CMake where to look for boost like this:
SET(CMAKE_INCLUDE_PATH ${CMAKE_INCLUDE_PATH} "C:/win32libs/boost")
SET(CMAKE_LIBRARY_PATH ${CMAKE_LIBRARY_PATH} "C:/win32libs/boost/lib")
Of course, those two lines have to be before the FIND_PACKAGE(Boost) in CMakeLists.txt.
There is more help available by reading the FindBoost.cmake file itself. It is located in your 'Modules' directory.
A good start is to set(Boost_DEBUG 1) - this will spit out a good deal of information about where boost is looking, what it's looking for, and may help explain why it can't find it.
It can also help you to figure out if it is picking up on your BOOST_ROOT properly.
FindBoost.cmake also sometimes has problems if the exact version of boost is not listed in the Available Versions variables. You can find more about this by reading FindBoost.cmake.
Lastly, FindBoost.cmake has had some bugs in the past. One thing you might try is to take a newer version of FindBoost.cmake out of the latest version of CMake, and stick it into your project folder alongside CMakeLists.txt - then even if you have an old version of boost, it will use the new version of FindBoost.cmake that is in your project's folder.
Good luck.
For me this error was simply because boost wasn't installed so on ubuntu:
sudo apt install build-essential libboost-system-dev libboost-thread-dev libboost-program-options-dev libboost-test-dev
I struggled with this problem for a while myself. It turned out that cmake was looking for Boost library files using Boost's naming convention, in which the library name is a function of the compiler version used to build it. Our Boost libraries were built using GCC 4.9.1, and that compiler version was in fact present on our system; however, GCC 4.4.7 also happened to be installed. As it happens, cmake's FindBoost.cmake script was auto-detecting the GCC 4.4.7 installation instead of the GCC 4.9.1 one, and thus was looking for Boost library files with "gcc44" in the file names, rather than "gcc49".
The simple fix was to force cmake to assume that GCC 4.9 was present, by setting Boost_COMPILER to "-gcc49" in CMakeLists.txt. With this change, FindBoost.cmake looked for, and found, my Boost library files.
You can also specify the version of Boost that you would like CMake to use by passing -DBOOST_INCLUDEDIR or -DBOOST_ROOT pointing to the location of correct version boost headers
Example:
cmake -DBOOST_ROOT=/opt/latestboost
This will also be useful when multiple boost versions are on the same system.
I also had a similar problem and discovered that the BOOST_INCLUDE_DIR, BOOST_LIBRARYDIR and BOOST_ROOT env variables must hold absolute paths.
HTH!
In my case Boost was not installed. I used below command on Mac and then cmake find_package(Boost) works like a charm
brew install Boost
Please note upper case 'B' in Boost!
If you are building your own boost do not forget to use the --layout=versioned otherwise the search for a particular version of library will fail
For cmake version 3.1.0-rc2 to pick up boost 1.57 specify -D_boost_TEST_VERSIONS=1.57
cmake version 3.1.0-rc2 defaults to boost<=1.56.0 as is seen using -DBoost_DEBUG=ON
cmake -D_boost_TEST_VERSIONS=1.57 -DBoost_DEBUG=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++
One more bit of advice for anyone trying to build CGAL in particular, with statically linked Boost. It is not enough to define Boost_USE_STATIC_LIBS; it gets overridden by the time Boost_DEBUG outputs its value. The thing to do here is to check the "Advanced" checkbox and to enable CGAL_Boost_USE_STATIC_LIBS.
I had the same problem while trying to run make for a project after installing Boost version 1.66.0 on Ubuntu Trusty64. The error message was similar to (not exactly like) this one:
CMake Error at
/usr/local/Cellar/cmake/3.3.2/share/cmake/Modules/FindBoost.cmake:1245 (message):
Unable to find the requested Boost libraries.
Boost version: 0.0.0
Boost include path: /usr/include
Detected version of Boost is too old. Requested version was 1.36 (or newer).
Call Stack (most recent call first):
CMakeLists.txt:10 (FIND_PACKAGE)
Boost was definitely installed, but CMake couldn't detect it. After spending plenty of time tinkering with paths and environmental variables, I eventually ended up checking cmake itself for options and found the following:
--check-system-vars = Find problems with variable usage in system files
So I ran the following in the directory at issue:
sudo cmake --check-system-vars
which returned:
Also check system files when warning about unused and uninitialized variables.
-- Boost version: 1.66.0
-- Found the following Boost libraries:
-- system
-- filesystem
-- thread
-- date_time
-- chrono
-- regex
-- serialization
-- program_options
-- Found Git: /usr/bin/git
-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/myproject
and resolved the issue.
See FindBoost.cmake first. The variables you set are the correct ones but they should be all uppercase.
Make sure the library architecture matches with CMake configuration.
cmake -A x64 ..
I suggest creating a minimal executable which only includes a Boost library to see if it compiles.
#include <iostream>
#include <boost/date_time.hpp>
int main() {
using namespace std;
using namespace boost::gregorian;
date today = day_clock::local_day();
cout << today << endl;
}
find_package(Boost REQUIRED COMPONENTS
date_time
)
include_directories(${Boost_INCLUDE_DIR})
link_directories(${Boost_LIBRARY_DIRS})
add_executable(test_boost "test_boost.cpp")
target_link_libraries(test_boost Boost::date_time)
Start debugging by checking Boost_FOUND first.
message(STATUS "Boost_FOUND: ${Boost_FOUND}")
The version should be found even if no libraries are found. (Boost_VERSION)
If Boost_LIBRARY_DIRS becomes non-empty, it should compile.
I had the same problem, and none of the above solutions worked. Actually, the file include/boost/version.hpp could not be read (by the cmake script launched by jenkins).
I had to manually change the permission of the (boost) library (even though jenkins belongs to the group, but that is another problem linked to jenkins that I could not figure out):
chmod o+wx ${BOOST_ROOT} -R # allow reading/execution on the whole library
#chmod g+wx ${BOOST_ROOT} -R # this did not suffice, strangely, but it is another story I guess
This can also happen if CMAKE_FIND_ROOT_PATH is set as different from BOOST_ROOT.
I faced the same issue that in spite of setting BOOST_ROOT, I was getting the error.
But for cross compiling for ARM I was using Toolchain-android.cmake in which I had (for some reason):
set(BOOST_ROOT "/home/.../boost")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --sysroot=${SYSROOT}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} --sysroot=${SYSROOT} -I${SYSROOT}/include/libcxx")
set(CMAKE_CXX_LINK_FLAGS "${CMAKE_CXX_LINK_FLAGS}")
set(CMAKE_FIND_ROOT_PATH "${SYSROOT}")
CMAKE_FIND_ROOT_PATH seems to be overriding BOOST_ROOT which was causing the issue.
For those using python3.7 docker image, this solved:
apt install libboost-system-dev libboost-thread-dev
Maybe
brew install boost
will help you.

Resources