When i try to run cmake to build a project where i include the SFML library i get the following Error: SFML found but version too low (requested: 2.4, found: 1.x.x)
I downloaded only the source of the newest Version of the library (SFML-2.4.2). I than run cmake (with MinGW Makefiles) And build the binaries into the same folder.
I copied the FindSFML into an subfolder of my project.
After that i had the following folder structure
SFML-2.4.2\
cmake\
Modules\
FindSFML.cmake
CMakeFiles
doc
...
include
lib
src
..
sfml-games\
tetris\
cmake_modules\
FindSFML.cmake
CMakeLists.txt
main.cpp
tetris-build
...
My CMakeLists.txt contains the following stuff:
project(Tetris)
cmake_minimum_required(VERSION 2.8)
aux_source_directory(. SRC_LIST)
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake_modules")
Find_package(SFML 2 REQUIRED system window graphics network audio)
include_directories(${SFML_INCLUDE_DIR})
add_executable(${PROJECT_NAME} ${SRC_LIST})
target_link_libraries(${PROJECT_NAME} ${SFML_LIBRARY})
I found that in cmake the entry CMAKE_INSTALL_PREFIX (which i dont get) is set to C:\Program Files (x86)\SFML so i put the library and the lib of SFML into C:\Program Files (x86)\SFML. (what is that CMAKE_INSTALL_PREFIX and should i realy always copy the library and lib folders into my C:\Program Files (x86)\ ??). Now my cmake runs through but when i try to compile the code i get a lot of undifined references to '_imp__....'
By the way on linux i just installed SFML via sudo apt-get install libsfml-dev and it works out of the box.
You're confusing things. CMAKE_INSTALL_PREFIX is the default location where to put SFML when you build the install target (i.e. running make install). This has nothing to do with your other issues.
You don't have to install SFML (or any other library) somewhere under C:\Program Files. That's completely up to you.
What I found to be rather neat is installing MinGW to C:\usr (or creating a symlink to your installation folder) and also use that path for CMAKE_INSTALL_PREFIX when building SFML.
This way MinGW should behave pretty much the way you're used to from Linux (i.e. not having to specify paths for include dir or libraries etc.).
As for your undefined reference errors, you should create a new question only asking for these (and then include at least a few of them), as they have nothing to do with the installation directory.
Right now I can only guess, but it's most likely due to you using the wrong CMake variables for the linker. You won't notice this on Linux, since SFML will be in the default search path (which will also happen if you use C:\usr as described above).
To try fixing this, use this line:
target_link_libraries(${PROJECT_NAME} ${SFML_LIBRARIES} ${SFML_DEPENDENCIES})
I've just build a gcc 5.2.0 on windows according to this material:
http://preshing.com/20141108/how-to-install-the-latest-gcc-on-windows/
Everything went well. But then I've tried to build Qt with this newly built gcc and I'm getting an error that there is no mingw32-make. Checked directory and no, there isn't one.
But then I checked previously installed gcc, which was work of TDM, downloaded from:
http://tdm-gcc.tdragon.net/
and yes, in his build there is mingw32-make.
So, the question is, how is it that he has that tool, and many other which are absent in my build are present in his?
if you create from the gcc5.2.0 source, a build then you've just created the gcc compiler with all its necessary files. e.g. gcc-5.2.0.exe, gcc.exe, g++.exe, etc.
NOT the MinGW runtime environment for gcc, which contains the mingw32-make.exe !
if you follow your link from your question here you build it with the cygwin make.exe.
It's better to download the mingw 32 binary runtime environment for gcc
or
MinGW64 runtime environment for gcc
Then you have all the files needed to work with QT.
if you want to create a mingw build from source, you need first a MinGW runtime environment then you can use that to build your own mingw32-make.exe.
I'm trying to build LLVM/Clang on Windows 7 with Microsoft C++ 2013. Building LLVM spat out a few error messages along the way but mostly seemed to be succeeding and did end up creating a folder full of exe's so that part seems to have worked. When I try to build Clang:
C:\clang>\CMake\bin\cmake.exe ..\clang-3.4 -DCLANG_PATH_TO_LLVM_BUILD=/llvm
CMake Error at CMakeLists.txt:29 (message):
Please set CLANG_PATH_TO_LLVM_BUILD to a directory containing a LLVM build.
And I get the same error message whether I omit CLANG_PATH_TO_LLVM_BUILD, define it in CMakeLists.txt or an environment variable instead of the command line, set it to possibly relevant subdirectories of /llvm etc.
What am I missing?
You're not following the instructions on this page correctly, under "Using Visual Studio". You will end up with
/
/llvm
/llvm/CMakeLists.txt
/llvm/tools/clang
/llvm/tools/clang/CMakeLists.txt
Step 4, repeated here for clarity:
Run CMake to generate the Visual Studio solution and project files:
cd ..\.. (back to where you started)
mkdir build (for building without polluting the source dir)
cd build
If you are using Visual Studio 2012: cmake -G "Visual Studio 11" ..\llvm
That last bit needs to be run from inside the VS Command Prompt, but you seem to have that sorted out. You can also generate "NMake makefiles" if you don't use the IDE to build. Anyways, the point is that you should call cmake on the toplevel CMakeLists.txt file, not on the clang one directly. Clang will be built as part of the build process. You can even add libc++ and compiler-rt to the llvm/projects directory to have these built automatically on platforms that support them.
What you are doing is building clang "out of tree". Which is possible and even supported, but only really useful in certain circumstances. You'll need a previously built build of LLVM in some directory. You then set CLANG_PATH_TO_LLVM_BUILD to the directory containing the built LLVM files (this is not the source directory). But as I said, that's making things needlessly difficult.
// brief version
How can I make CMake to use my supplied zlib (which it also has to build from source) instead of the one found by the finder without breaking the finder for other libs (OpenGL)?
ZLib needs to be used by the main project and also libPNG which comes as source as well.
Primary target platform is Windows.
// longer version:
In my project I need to link against libpng, zlib and OpenGL. With libpng being dependent on zlib. But zlib is also required by the main project.
I need to supply sourcecode for all libs except OpenGL, and build those libraries along with
the main project to assert linking the correct version and simplify building on Windows.
I found ways to do all this with custom libraries where no built-in finder exists, but I can't override the finder properly for just zlib. If I change the search path for libs, then OpenGL is not found.
However I can't get cmake to use my supplied zlib instead of a rouge zlib.DLL that the package finder finds somewhere in my system. (The one from tortoise git)
I tried to set ZLIB_LIBRARY to a specific filepath, but that only works on MinGW, and I also think this is not the way to do it.
(And also I had to explicitly link to png16_static instead of just libpng, for an inexplicable reason.)
Any help on this is much appreciated. Maybe I'm taking this on the wrong way?
Target&Development Platform:
Windows7
Visual Studio 2010
and MinGW (both need to work)
My (simplified example) CMakeLists.txt:
cmake_minimum_required (VERSION 2.6)
project (MyProject)
find_package(OpenGL)
add_executable(MyProject main.cpp)
include_directories(${INCLUDE_DIRECTORIES} "${PROJECT_BINARY_DIR}")
include_directories(${INCLUDE_DIRECTORIES} "external_libs/lpng162")
include_directories(${INCLUDE_DIRECTORIES} "external_libs/zlib-1.2.8")
include_directories(${INCLUDE_DIRECTORIES} "${PROJECT_BINARY_DIR}/external_libs/zlib-1.2.8")
add_subdirectory("external_libs/zlib-1.2.8")
link_directories(${LINK_DIRECTORIES} "${PROJECT_BINARY_DIR}/external_libs/zlib-1.2.8")
# libpng will not build correctly if this not set
set (ZLIB_ROOT "${PROJECT_SOURCE_DIR}/external_libs/zlib-1.2.8")
# manually set this to prevent cmake from finding the tortiose-git zlib.dll first
# DOES NOT WORK CORRECTLY, only with mingw32
set (ZLIB_LIBRARY "${PROJECT_BINARY_DIR}/external_libs/zlib-1.2.8/libzlib.dll")
add_subdirectory("external_libs/lpng162")
TARGET_LINK_LIBRARIES(MyProject png16_static zlib ${OPENGL_LIBRARY})
Project (simplified example) structure:
./main.cpp
./CMakeLists.txt
./external_libs/zlib-1.2.8/ <- contains respective source
./external_libs/lpng162/ <- contains respective source
Third-party libraries most likely call FindZLIB.cmake to determine the location of CMake. You already had the right idea by setting the ZLIB_LIBRARY manually, but were not quite getting it right:
add_subdirectory(<path_to_zlib_src_dir>)
set(ZLIB_INCLUDE_DIR "<path_to_zlib_src_dir>" "${CMAKE_BINARY_DIR}/<path_to_zlib_build_dir>")
set(ZLIB_LIBRARY zlib)
add_subdirectory(<path_to_lpng_src_dir>)
The include directory needs to contain both src and build path as zconf.h is build by CMake
The library name is only the CMake-target name, not the complete path to the resulting file.
On Windows dlls are not automatically copied by CMake. You might want to add some additional code to make sure that the zlib and lpng dlls end up in the right place.
You can call find_package(zlib) yourself to make sure it behaves as expected
In the rare case that a third-party lib does not use the find script, you will have to dig into that project's CMakeLists to find out what is going on
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.