I my library I use boost's float128 wrapper therefore changing the compiler is not an option.
Following Intel's developer guide I added find_package(IntelDPCPP REQUIRED) to my CMakeLists.txt and ran cmake -DCMAKE_C_COMPILER=icx -DCMAKE_CXX_COMPILER=icx -GNinja on the VS 2022 terminal. I get the following error message
Found package configuration file:
C:/Program Files (x86)/Intel/oneAPI/compiler/latest/windows/IntelDPCPP/IntelDPCPPConfig.cmake
but it set IntelDPCPP_FOUND to FALSE so package "IntelDPCPP" is considered
to be NOT FOUND. Reason given by package:
Unsupported compiler family and compiler icx!!
Anyone with a similar issue that can help out?
EDIT: as suggested by #Botje here the output information relevant to this case
IntelDPCPPConfig.cmake(84): string(COMPARE EQUAL ${CMAKE_CXX_COMPILER} nocmplr )
IntelDPCPPConfig.cmake(85): if(nocmplr)
IntelDPCPPConfig.cmake(93): if(NOT x${CMAKE_CXX_COMPILER_ID} STREQUAL xClang AND NOT x${CMAKE_CXX_COMPILER_ID} STREQUAL xIntelLLVM )
IntelDPCPPConfig.cmake(95): set(IntelDPCPP_FOUND False )
This is a known issue, it will be fixed in the OneAPI 2023.1 release.
You can try reversing the order of find_package and project or removing find_package(IntelDPCPP REQUIRED) in CMakeLists.txt. Because CMake identifies and sets up all the compiler-related variables when the project() is called.
Also, you can set the compiler option for the DPC++ compiler in CMakeLists.txt using the below command.
set(CMAKE_CXX_COMPILER dpcpp)
Background
I'm a complete newb with C++ and I've been running into one headache after another, so forgive me if this is incredibly simple and I'm just that dumb...
I have a project that should ultimately compile and run in Linux. Unfortunately after lots of issues with my C++ development environemnt (still unresolved), I gave up on trying to develop in Linux and moved to Windows Visual Studio 2017. My hope was to get my code working in Windows and then, since C++ is supposedly a portable language, it should just work in Linux with minimal changes.
For a day or so Visual Studio seemed to be working. I could write code, hit "compile", and like magic it would run. I threw together a few classes to construct a directed acyclic graph, used the standard library for a hash table, and then I tried to create a socket...
Windows and Linux use different libraries for sockets (<sys/socket.h> vs <winsock.h>) so I needed some way to abstract the differences, and I preferred a well-established standard. Googling around I found the Boost library that seemed to fit my needs... That's when everything went to hell.
My project setup
Because this project will be developed across a variety of platforms and IDEs (some people use Windows + Visual Studio, some people use Mac + Eclipse, and others use Linux + VIM) I opted to make it a CMake project. After several hours of reading and learning and research it seems like CMake should give me what I want (convenient and reproducible cross-platform builds with little or no dependency issues)
My source code (directly from the Boost Getting Started on Windows guide) is as follows:
CMakeProject2.cpp
#include <boost/lambda/lambda.hpp>
#include <iostream>
#include <iterator>
#include <algorithm>
int main()
{
using namespace boost::lambda;
typedef std::istream_iterator<int> in;
std::for_each(
in(std::cin), in(), std::cout << (_1 * 3) << " ");
}
Per the Boost Getting Started on Windows guide, I downloaded Boost from here:
https://dl.bintray.com/boostorg/release/1.67.0/source/boost_1_67_0.zip
(interestingly, the Getting Started guide is titled "Boost Getting Started on Windows - 1.69.0", yet it linked to Boost versions 1.67.0)
After downloading and extracting the ZIP file, I had a whole mess of files - but no idea where to put them:
Attempts to Get It Working So Far
I tried to add the Boost library to my project, but none of the expected menu options were available:
Although I couldn't find a single page that warns you of this gotcha, apparently CMake projects don't have the elusive "Properties" window - and instead third party libraries must somehow be included via the CMakeLists.txt file
For starters, I copied the entire 540 MB contents of the Boost ZIP file to within my project under the folder name "Boost":
I then tried a series of different CMakeList.txt commands:
Per How do you add Boost libraries in CMakeLists.txt?:
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
find_package(Boost REQUIRED COMPONENTS lambda)
if(Boost_FOUND)
include_directories(${Boost_INCLUDE_DIRS})
add_executable(CMakeProject2 "CMakeProject2.cpp" "CMakeProject2.h")
target_link_libraries(CMakeProject2 ${Boost_LIBRARIES})
endif()
Per https://www.selectiveintellect.net/blog/2016/7/29/using-cmake-to-add-third-party-libraries-to-your-project-1:
include("Boost")
add_subdirectory("Boost")
add_subdirectory("boost")
add_subdirectory("Boost/boost")
add_subdirectory("Boost/boost/lambda")
target_link_libraries(boost)
target_link_libraries(Boost)
Per https://cmake.org/pipermail/cmake/2009-November/033249.html:
SET (Boost_FIND_REQUIRED TRUE)
SET (Boost_FIND_QUIETLY TRUE)
SET (Boost_DEBUG FALSE)
set (Boost_USE_MULTITHREADED TRUE)
set (Boost_USE_STATIC_LIBS TRUE)
SET (Boost_ADDITIONAL_VERSIONS "1.67" "1.67.0")
FIND_PACKAGE(Boost COMPONENTS lambda)
INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIRS})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})
I tried several other incantations (not being familiar with C++ or CMake as a tool) and either received errors from CMakeLists.txt, or from CMakeProject2.cpp about cannot open source file "boost/lambda/lambda.hpp". In fact, with regards to those "CMakeLists.txt" errors, after adding enough lines to my file I started to crash Visual Studio regularly. Note that I have an 8th generation i7, 32 gigabytes of RAM, and an M.2 NVMe hard drive -- so I was rather impressed that a few lines in a text file pissed off Microsoft enough to lock up my computer for 10 minutes at a time.
Failing all of that, I tried copying the files I needed directly into my project:
Now, again, I'm new to C/C++ development and everything that can go wrong has gone wrong. So far I've spent almost two weeks and barely managed to compile a single "Hello, World" app across two computers, three IDEs, and four compilers. I've yet to have any success including a third party library, from anywhere, of any popularity level or simplicity level, and actually compile a functioning program that references the library. So believe me when I say: I don't know the difference between a "header-only library" and... whatever the alternative is. I just know that, according to the Boost Getting Started on Windows guide, most of Boost is "headers only" and therefore I shouldn't have any build step -- it should be simple to use it. Furthermore, this example (using boost::lambda) is - per their instructions - a header-only library, and should therefore be extremely easy to use.
I now updated the source code slightly to look in the current directory, instead of looking in the system include directory (which, as far as I'm aware at this point, doesn't exist in Windows):
#include "boost/lambda/lambda.hpp"
#include <iostream>
#include <iterator>
#include <algorithm>
int main()
{
using namespace boost::lambda;
typedef std::istream_iterator<int> in;
std::for_each(
in(std::cin), in(), std::cout << (_1 * 3) << " ");
}
Now I can manually verify that this file exists (the file CMakeProject2\CMakeProject2\boost\lambda\lambda.hpp can be found in File Explorer) - yet I'm still getting errors:
cannot open source file "boost/lambda/lambda.hpp"
Some further Googling led me to update my CMakeLists.txt file once more, putting it in its current form:
# CMakeList.txt : CMake project for CMakeProject2, include source and define
# project specific logic here.
#
cmake_minimum_required (VERSION 3.8)
# Add source to this project's executable.
file(GLOB CMakeProject2_SRC
"*.h"
"*.cpp"
"**/*.h"
"**/*.cpp"
"**/*.hpp"
"boost/lambda/lambda.hpp"
)
add_executable (CMakeProject2 ${CMakeProject2_SRC})
#add_executable (CMakeProject2 "CMakeProject2.cpp" "CMakeProject2.h")
# TODO: Add tests and install targets if needed.
Despite this I'm still getting the error:
cannot open source file "boost/lambda/lambda.hpp"
At this point I'm ripping my hair out. What am I doing wrong? What do I not know? How is something as simple as the Boost-equivalent of "Hello, World" not working for me?
Following recipe should work
Download Boost binaries from official boost binaries location and install to say C:\Boost
Most times you do not need to build Boost on your own.
Your CMakeLists.txt should look like follows
cmake_minimum_required (VERSION 3.8)
project(boostAndCMake)
set(BOOST_ROOT "C:\Boost") # either set it here or from the command line
set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
find_package(Boost REQUIRED COMPONENTS system) # header only libraries must not be added here
add_executable(CMakeProject2 CMakeProject2.cpp CMakeProject2.h)
target_include_directories(CMakeProject2 PUBLIC ${Boost_INCLUDE_DIRS})
target_link_libraries(CMakeProject2 ${Boost_LIBRARIES})
Because we used REQUIRED on the find_package call, CMake will fail execution and skip the rest of the script if it cannot be found. So no need to check Boost_FOUND. You need to check it, when you omit REQUIRED.
Now from the command line call from the directory where your script resides:
cmake -H. -Bbuildit -G "Visual Studio 15 2017" -DBOOST_ROOT=C:\Boost
This creates a build directory named buildit in the current directory, further creates a solution for Visual Studio 2017 inside the build directory and provides the setting for the variable BOOST_ROOT that is used in the find_package call to identify the Boost directory on your computer. To see what options are available on the find_package(Boost ...) call see FindBoost documentation in CMake.
Header Only Libraries
If your libraries are header only you need to omit them from the find_package(Boost ...) call. To see which libraries are not header only see this post.
Using newer Boost versions
If your CMake installation cannot find the requested version, e.g. 1.69.0, but supports the naming scheme of the more recent Boost version you can use it with set(Boost_ADDITIONAL_VERSIONS "1.69.0" "1.69"). Last change of the Boost naming scheme was from 1.65.1 to 1.66.
Here's a working setup for Boost 1.68 with CMake 3.12. Boost 1.69 is apparently "too new" for cmake to detect it properly. Since boost is not buildable by cmake, cmake itself must provide a FindBoost.cmake module that must keep up with boost changes.
So anyway, the CMakeLists.txt is as small as this:
cmake_minimum_required(VERSION 3.11)
project(foobar)
find_package(Boost 1.68 REQUIRED)
add_executable(foo foo.cpp)
target_link_libraries(foo PUBLIC Boost::boost)
Of course, you can split it in many subdirectories.
Invoking CMake in the command line should look like this:
cmake -DCMAKE_PREFIX_PATH=path_to_local_directory ..
Where path_to_local_directory is the installation path of all library you want to depend on. It will work for Boost, nlohmann_json, glfw3, Qt, you name it *(1). For my case, it was C:/local/ and another case was ../external/ (yes, it can be a directory local to the project!)
Let's take a peek at my own C:/local/:
ls -l /c/local/
total 12
drwxr-xr-x 1 myself 197609 0 May 26 2018 boost_1_67_0/
drwxr-xr-x 1 myself 197609 0 Sep 5 02:02 boost_1_68_0/
WARNING: Ensure your compiler architecture is the same as the installed boost version. Or else cmake will simply not find it.
I think that about it. The next CMake version (3.14) should work with the latest boost.
*(1) The said library will either need to export it's CMake target or you must provide a FindXXX.cmake
I'm using CMake 3.22 with Boost version 1.78.
The simplest solution is to set the Boost_INCLUDE_DIR when calling Cmake:
cmake -DBoost_INCLUDE_DIR=boost
Pass the directory to where the Boost libraries are. If you're using Visual Studio you can also set this in your CMake Settings:
Or, in the CMakeSettings.json file:
"cmakeCommandArgs": "-DBoost_INCLUDE_DIR=boost",
In my opinion, this is better than using the set function because you're not hard coding the path.
Add a target_include_directories(CMakeProject2 PRIVATE .) into your CMakeList.txt.
The . is the relative path of boost/lambda/lambda.hpp from CMakeLists.txt
And you should not add any .hpp file to the source list.
I have written a tutorial project whilst trying to understand the use of run-path dependent libraries on macOS and Linux. simpleapp depends on libmymaths, which in turn depends on libfastmatrix. libmymaths is a run-path dependent library and you can see the structure of the project here. I am trying to use the OS specific macros (#executable_path for macOS and $ORIGIN for linux) in order to allow the binaries to be easily moved around without breaking, since their location is going to be resolved during run-time and substituted in the macros. However, although what I've programmed so far works nicely on macOS, it doesn't on Linux. Specifically, I'm getting the following error during the linking stage of simpleapp (you can reproduce simply with ./run.sh):
/usr/bin/ld: warning: libfastmatrix.so, needed by /home/thomas/Developer/rpath_tutorial/libmymaths/libmymaths.so, not found (try using -rpath or -rpath-link)
In libmymaths' CMakeLists.txt I specify the rpath where its dependency (libfastmatrix) can be found, and that's verifiable with ldd libmymaths.so once libmymaths is built.
if(APPLE)
set(TOKEN "#loader_path")
elseif(UNIX AND NOT APPLE)
set(TOKEN "$ORIGIN")
endif()
set_target_properties(${PROJECT_NAME} PROPERTIES
CXX_STANDARD 11
CXX_EXTENSIONS FALSE
BUILD_WITH_INSTALL_RPATH TRUE
INSTALL_NAME_DIR "#rpath" # Necessary prior CMP0042 introduction.
INSTALL_RPATH "${TOKEN}/../libfastmatrix"
)
I have implemented the ld's suggestions as Fix 1 and Fix 2 in simpleapp's main CMake script, which allows the project to build.
# # Fix 1, -rpath-link (linux-specific ld option)
# LINK_FLAGS "-Wl,-rpath-link,${CMAKE_CURRENT_SOURCE_DIR}/../libfastmatrix/"
# # Fix 2, additional (unecessary for macOS) rpath, overwrites line 47
# INSTALL_RPATH "${TOKEN}/../libmymaths;${CMAKE_CURRENT_SOURCE_DIR}/../libfastmatrix"
However, this is against what I'm trying to achieve - make each library responsible for its own dependencies and not contaminate other projects with dependencies of dependencies.
1) What changes do I need to make to achieve my goal on Linux as I have done on macOS?
2) In case this is not feasible because the whole approach I am taking is incorrect, can you provide some proof or sources where this is documented?
I'm using:
CMake 3.5.1
ld 2.26.1
gcc 5.4.0
Thanks.
I do this with my game project. Here are the steps I use to make it work.
cmake_minimum_required(VERSION 3.5)
if (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(CMAKE_INSTALL_RPATH "$ORIGIN/lib/:$$ORIGIN/lib/")
endif()
if (${CMAKE_SYSTEM_NAME} MATCHES "Linux")
install(TARGETS SpeedBlocks DESTINATION ${PROJECT_SOURCE_DIR}/build)
endif()
Note that I'm using a higher CMAKE version, so could be a bit different from what you need to do in 2.8.
After this I need to build the project, then run make install. The built binary will not have the RPATH set properly, but when I run make install (which basically just copies the binary and applies the RPATH from what I can tell) it gets set properly.
You can check if a binary has RPATH set properly by using
objdump -x path_to_binary_or_lib | grep RPATH
should output something like
RPATH $ORIGIN/lib/:$$ORIGIN/lib/:/usr/local/lib
I want to use CMake in my software that uses MagickWand.
CMake works on my machine and generates a useful Makefile.
On another machine, I have to manually add
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -lMagickWand-6.Q16 -lMagickCore-6.Q16")
otherwise the linker can't find MagickWandGenesis() and other functions.
I found that -l flags via pkg-config --cflags --libs MagickWand.
Shouldn't CMake already generate linker flags for me with TARGET_LINK_LIBRARIES?
Did I miss something obvious, or why is this not working everywhere?
I have this code in CMakeLists.txt:
FIND_PACKAGE(ImageMagick
REQUIRED
COMPONENTS MagickWand
)
[...]
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16")
[...]
INCLUDE_DIRECTORIES(
${Boost_INCLUDE_DIR}
${ImageMagick_INCLUDE_DIRS}
${ImageMagick_MagickWand_INCLUDE_DIRS}
)
[...]
TARGET_LINK_LIBRARIES(application_name
[...]
${Boost_LIBRARIES}
${CURL_LIBRARIES}
${ImageMagick_LIBRARIES}
${ImageMagick_MagickWand_LIBRARY}
)
That last ${ImageMagick_MagickWand_LIBRARY} shouldn't even be necessary.
Using Magick 6.8.9.9, CMake 3.0.2 on both machines (Debian Jessie).
Short answer: the package ImageMagick is buggy.
Looking in CMake's sources, the REQUIRED mechanism is handled exclusively through the variable package-_FOUND, independently of the required components.
Looking in the package ImageMagick here, ImageMagick_FOUND is set as follows:
set(ImageMagick_FOUND ${IMAGEMAGICK_FOUND})
But IMAGEMAGICK_FOUND is not set anywhere in the package, so the call will always unset ImageMagick_FOUND, and it will always be evaluated to true (not actively set to false), wether or not the components are effectively found.
You can either debug the package (and propose a pull request) or check the component variable:
if(NOT ImageMagick_MagickWand_FOUND)
message(FATAL_ERROR "MagickWand not found")
endif()
I guess the test will fail on your second machine.
By the way, you should only use ImageMagick_INCLUDE_DIRS and ImageMagick_LIBRARIES to link to the library (the ImageMagick_MagickWand* variables are here redundant). If you choose to debug the package, you may also declare imported targets.
Figured it out, despite the output of
MESSAGE(${ImageMagick_FOUND})
MESSAGE(${ImageMagick_INCLUDE_DIRS})
MESSAGE(${ImageMagick_LIBRARIES})
MESSAGE(${ImageMagick_MagickWand_FOUND})
MESSAGE(${ImageMagick_MagickWand_INCLUDE_DIRS})
MESSAGE(${ImageMagick_MagickWand_LIBRARY})
being identical, the installed packages differed. I installed the magick-dev packages via virtual packages in aptitude, which for some reason used the graphicsmagick suite for some packages (a imagemagick fork) instead of the original imagemagick suite.
For reference, the used aptitude search one-liner was aptitude search 'magick ?installed' | sort which listed three graphicsmagick packages on the second machine where imagemagick packages were on the first machine.
[EDIT] I have now been able to make progress and build my project with OpenCV and all its dependencies linked in statically. I have tried to answer my questions (below) as well as I could, but there are still remaining questions.
In order to be able to link OpenCV into a library I am developing (a plugin for X-Plane fligt sim) I am building it as a static library using cmake's -DBUILD_SHARED_LIBS=OFF flag.
I also need the Qt GUI backend and at first I just had Qt shared libs installed on my system. OpenCV build did recognize these, but apparently they didn't get linked into OpenCV statically because I was getting undefined symbols at runtime in my app after linking against my built OpenCV libs. Why did the app not use the shared Qt libs?
I am assuming that when I link an object in statically it will only attempt to find its dependencies statically too, it won't try and go for shared libs on the system. I would still appreciate clarification in this point.
So, I figured I need to have static Qt libs and point the OpenCV build at them. Can you confirm this is correct thinking or possibly explain why not?
I was able to link shared libs (.so) into my app so the answer is no, I don't have to use static libraries when I want to link them into my application. Also OpenCV doesn't link Qt in so when you need the OpenCV Qt support in your application, you need to link Qt in yourself.
One important thing I got bitten by is that when linking the libraries must be presented to GCC linker in the order of their dependencies - always list dependencies of an object AFTER the object itself.*
So I built Qt 5.2.0 as static libs, installed on my system and pointed the OpenCV build at these with an environment variable: CMAKE_PREFIX_PATH=/usr/local/Qt-5.2.0
This worked at least partially, because I could see the new location being used by cmake, but I started getting the following cmake error:
CMake Error at cmake/OpenCVUtils.cmake:344 (foreach):
Syntax error in cmake code at
/home/martin/Work/Hack/libs/opencv-2.4.8/cmake/OpenCVUtils.cmake:344
when parsing string
${Qt5::Core_LIB_DEPENDS}
syntax error, unexpected cal_SYMBOL, expecting } (24)
Call Stack (most recent call first):
cmake/OpenCVModule.cmake:843 (ocv_split_libs_list)
cmake/OpenCVModule.cmake:886 (__ocv_track_module_link_dependencies)
CMakeLists.txt:544 (ocv_track_build_dependencies)
Would you know what is causing this error?
I abandoned trying to build OpenCV against static Qt5, so this is no longer relevant, and I haven't found an answer. Still may be of usse to others if osmeone knew what this problem is.
Below is the relevant part of the OpenCVModule.cmake file.
get_target_property(__module_type ${the_module} TYPE)
if(__module_type STREQUAL "STATIC_LIBRARY")
#in case of static library we have to inherit its dependencies (in right order!!!)
if(NOT DEFINED ${the_module}_LIB_DEPENDS_${optkind})
vvvvvvvvvv issue on the line below vvvvvvvvvvvvvvvvvv
ocv_split_libs_list(${the_module}_LIB_DEPENDS ${the_module}_LIB_DEPENDS_DBG ${the_module}_LIB_DEPENDS_OPT)
endif()
set(__resolved_deps "")
set(__mod_depends ${${the_module}_LIB_DEPENDS_${optkind}})
set(__has_cycle FALSE)
while(__mod_depends)
list(GET __mod_depends 0 __dep)
list(REMOVE_AT __mod_depends 0)
if(__dep STREQUAL the_module)
set(__has_cycle TRUE)
else()#if("${OPENCV_MODULES_BUILD}" MATCHES "(^|;)${__dep}(;|$)")
ocv_regex_escape(__rdep "${__dep}")
if(__resolved_deps MATCHES "(^|;)${__rdep}(;|$)")
#all dependencies of this module are already resolved
list(APPEND ${the_module}_MODULE_DEPS_${optkind} "${__dep}")
else()
get_target_property(__module_type ${__dep} TYPE)
if(__module_type STREQUAL "STATIC_LIBRARY")
if(NOT DEFINED ${__dep}_LIB_DEPENDS_${optkind})
ocv_split_libs_list(${__dep}_LIB_DEPENDS ${__dep}_LIB_DEPENDS_DBG ${__dep}_LIB_DEPENDS_OPT)
endif()
list(INSERT __mod_depends 0 ${${__dep}_LIB_DEPENDS_${optkind}} ${__dep})
list(APPEND __resolved_deps "${__dep}")
elseif(NOT __module_type)
list(APPEND ${the_module}_EXTRA_DEPS_${optkind} "${__dep}")
endif()
endif()
#else()
# get_target_property(__dep_location "${__dep}" LOCATION)
endif()
endwhile()