Where multiple possible versions of a library exist, is there a way of ensuring cmake picks the "right" one?
For example: centOS7 comes with gcc 4.5.2, and includes /usr/lib64/libgfortran.so.1. I have compiled gcc 6.2.0 in /usr/local, and this includes /usr/local/gcc-6.2/libgfortran.so.3
However,
find_package(Gfortran REQUIRED)
Always finds the system gfortran. My "FindGfortran.cmake" file contains:
find_library(Gfortran_LIBRARY
NAMES gfortran
PATHS /usr/local/gcc-6.2/lib64
)
And I've set tried running cmake with:
LD_RUN_PATH='/usr/local/gcc-6.2/lib64' LDFLAGS='-L/usr/local/gcc-6.2/lib64' CXXFLAGS='-L/usr/local/gcc-6.2/lib64' cmake ..
But whatever I do, cmake picks up the /usr/lib64/libgfortran.so.1 version (and then my code fails because it links, correctly, against a different library which is in turn linked against libgfortran.so.3).
I have a "workaround" in that I can edit my CMakeLists.txt file to include the line:
set (Gfortran_LIBRARIES /usr/local/gcc-6.2/lib64/libgfortran.so.3)
But this is rather rubbish, and means that I need to maintain different CMakeLists.txt files on different machines (so I can't commit the file to SVN) which seems to defy the point of using cmake.
There must be something stupid I'm doing wrong - can anyone advise?
Related
I am looking to set various compilers for different folders in my project, which should compile to a shared library.
The project structure is as follows -
/Cuda
a.cu
b.cu
c.cu
header.cuh
/SYCL
a.cpp
b.cpp
c.cpp
header.h
main.cpp
test.cpp
All the files under the Cuda folder must be compiled by nvcc, and the files under the SYCL folder by a specific compiler that is present at a path in the system. All the files outside these folders (namely main.cpp and test.cpp) are normal C++ code and use the headers present in these two folders and must be compiled with GCC.
How do I go about writing the CMake for such a project structure(which aims to be a shared lib).
Edit - The project needn't have only one dedicated CMake. My approach was as follows -
Each Folder(Cuda and SYCL) can have their dedicated CmakeLists.txt which would specify the compiler and the various flags to go with it.
A master CMake outside the folder can use the add_subdirectory command. And this is where I get stuck, I am not sure what to do next, how to link these two folders with the main and the test files.
CMake allows one compiler per language, so simply writing this is enough:
cmake_minimum_required(VERSION 3.20)
project(example LANGUAGES CXX CUDA)
add_subdirectory(Cuda)
add_subdirectory(SYCL)
You can separately set the C++ and CUDA compilers by setting CMAKE_CXX_COMPILER and CMAKE_CUDA_COMPILER at the configure command line.
$ cmake -S . -B build -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_CXX_COMPILER=g++ -DCMAKE_CUDA_COMPILER=nvcc
Also, I want to clear up this misconception:
Each Folder(Cuda and SYCL) can have their dedicated CmakeLists.txt which would specify the compiler and the various flags to go with it.
The CMakeLists.txt file should not attempt to specify the compiler. It's tricky to do correctly, can't always be done (especially in the add_subdirectory case) and unnecessarily restricts your ability to switch out the compiler. Maybe you have both GCC 10 and 11 installed and want to compare the two.
Similarly, you should not specify flags in the CMakeLists.txt file that aren't absolutely required to build, and you should always check the CMake documentation to see if the flags you're interested in have been abstracted for you. For instance, CMake has special handling of the C++ language standard (via target_compile_features) and CUDA separable compilation (via the CUDA_SEPARABLE_COMPILATION target property).
The best solution, as I have detailed here, is to set optional flags via the *_FLAGS* variables in a preset or toolchain.
I am trying to build a cross platform school project in C++ with CMake. My project requires the use of the Irrlicht library and must compile under Linux and Windows 10.
The project source path contains a lib folder, containing the Irrlicht header (in an include subfolder), an Irrlicht.dll, an Irrlicht.lib and a FindIrrlicht.cmake module.
I set CMAKE_MODULE_PATH to point to this directory, then call find_package(Irrlicht REQUIRED) in my CMakeLists.txt.
When I try to compile under Linux, everything works fine. However, when I try to run the configuration with CMake (using the CMake GUI) under Windows, the FindIrrlicht.cmake module that I have does not work (it should, since it is provided by the school and they say it should, also I know other people had it work without modifications). I believe that I have identified the cause of the problem, but I do not understance why it occurs nor how to fix it.
FindIrrlicht.cmake looks for the include directory and the Irrlicht.lib (or libIrrlicht.so under Linux, using prefix/suffix options) in some standard Linux include/library path AND under CMAKE_MODULE_PATH. When compiling on Windows, it should find everything in CMAKE_MODULE_PATH.
It calls find_library like this:
FIND_LIBRARY(Irrlicht_LIBRARIES
NAMES
Irrlicht
PATHS
"/usr/lib64/"
"/usr/lib/"
"/usr/lib/x86_64-linux-gnu/"
"/usr/local/lib/"
"/usr/local/lib64/"
"${CMAKE_MODULE_PATH}/" #Should find in this path for Windows configuration
"${Irrlicht_DIR}/"
)
The problem is, the path in CMAKE_MODULE_PATH is correct, since find_path() (see below) is able to find the include directory for Irrlicht. But it sets the Irrlicht_LIBRARIES as NOTFOUND. I verified times and again that the files are there and that the files are in the right place. I also checked the permissions on the files.
IF (NOT Irrlicht_INCLUDE_DIRS OR NOT Irrlicht_LIBRARIES)
FIND_PATH(Irrlicht_INCLUDE_DIRS
NAMES
irrlicht.h
PATHS
"/usr/include/irrlicht/"
"/usr/local/include/irrlicht/"
"${CMAKE_MODULE_PATH}/include/" #Does find in Windows
"${Irrlicht_DIR}/include/"
)
Also, later in the CMakeLists.txt I call a file(COPY "${CMAKE_MODULE_PATH}/Irrlicht.dll" DESTINATION ${EXECUTABLE_OUTPUT_PATH}) successfully, and tried it too with Irrlicht.lib with success. So the path is definitely not the problem here.
Thank you in advance for any help !
P.S.: This is my first time asking a question on StackOverflow, if I did/wrote something not right please let me know, I would be grateful.
Well, I found my problem. I feel stupid for not thinking about this sooner...
The problem was in the pre/suffixes, with some debugging output I realised that they were set for Linux instead of Windows, hence not founding the library file.
The reason for that is that in the CMakeLists.txt, the call to find_package was done before the call to project(), thus the MSVC variables was not set during the call to find_package, which led the script to believe it was called under Linux.
I am trying to compile a single codebase with references to both protobuffers 3.4.1 and 2.6.1. Now the 2.6.1 variant is globally defined as I am using ubuntu xenial, also:
$ protoc --version
yields:
libprotoc 2.6.1
The requirement for protobuffer version 3.4.1 comes from Google Cartographer (https://github.com/googlecartographer/cartographer) while the requirement for 2.6.1 comes from rotors simulator (https://github.com/ethz-asl/rotors_simulator) as it relies on Gazebo-7 (which uses protobuffer 2.6.1). In order to compile Google Cartographer I have added the binaries (added them in a proto3 folder, see below) to the installation by adapting the CMakeList.txt (see original file here: https://raw.githubusercontent.com/googlecartographer/cartographer/master/CMakeLists.txt) for Google Cartographer by adding the following lines:
set(CMAKE_PREFIX_PATH CMAKE_PREFIX_PATH "${CMAKE_SOURCE_DIR}/proto3")
...
install(DIRECTORY proto3/ DESTINATION .)
So the binaries of the protobuffer 3.4.1 are added to the install folder. I am utilizing catkin-tools (https://catkin-tools.readthedocs.io/en/latest/) to build the whole workspace. Now in a CMakelist.txt for Rotors Simulator I have the following line:
find_package(Protobuf 2.6.1 REQUIRED HINTS "/usr")
But at the moment while trying to compile it does not seem to be able to find the protobuffer 2.4.1 as it returns the following:
Could not find a configuration file for package "Protobuf" that is
compatible with requested version "2.6.1".
The following configuration files were considered but not accepted:
/home/jochem/catkin_ws/install/lib/cmake/protobuf/protobuf-config.cmake,
version: 3.4.1
As a side-note, if I compile the packages separately I am able to compile and install the packages. This is done with the following commands:
catkin build cartographer_ros
and
catkin build rotors_gazebo_plugins
I am at the moment trying to adapt the package of rotors_gazebo_plugins but am so far unsuccessful at making sure the correct protobuffer library is selected, am I missing something by defining references to a local protobuffer version?
You will find it possible to build a single executable that references 2 versions of the same library on mac, quite difficult on windows, and pretty much impossible on unix. This is because the symbol names are not distinct between the two libraries, so if you load both libraries, there is no way to know which library should service which call.
If you are building 2 different executables in one makefile package, then you just need to set the right libraries to load in the link stage. In linux, libraries are usually installed on your system with a version-number suffix, and a symlink that publishes the latest version without the version number. Normally you simply link to the unsuffixed latest version, but in your case, in your link command you will need to explicitly add the suffix.
If you really do need to link this cobble-together into a single executable, on unix you can do a lot with objcopy --redefine-syms to rename all the entrypoints in one of the libraries, and all the references in the dependant code all after compilation, but before linking. Note that the intended end result is that both libraries will run independently and will not be aware of each other.
If you will be able to wrap up at least one of the libs (i.e. either Cartographer or Rotors or both) into a separate shared library, and if the protobuff is only used internally in each of them, you still might be able to use them both in a single executable by building the shared libs with -fvisibility=hidden gcc flag (to switch the default visibility to hide symbols) and only exporting the symbols that are needed (that the app is using) via __attribute__((visibility("default"))).
This way I recall I was able to use two completely different Boost versions in the past, in the same app (by the shared lib not exporting the boost symbols linked in statically).
I have been trying to use SFML in a CMake project, specifically the header SFML/Audio.hpp. I installed SMFL using Homebrew, and both the .dylib-files and the headers should be located correctly, in /usr/local/lib and /usr/local/include, respectively.
Now running CMake works fine, telling me that it has Found SFML 2.4.2 in /usr/local/include.
However, when compiling the project (using make), I get the following error:
/path/to/project.hpp:12:10: fatal error: 'SFML/Audio.hpp' file not found.
Does anyone know why this is happening?
Note: Compiling works fine for colleagues of mine using the same CMake- and source files on various Linux operating systems.
This sounds like you simply forgot to add SFML's include directory. On Linux, they probably install SFML to some system path where GCC (or Clang) look by default, so they don't need any additional CMake directives.
Luckily, fixing this is pretty simple.
Add the following line to your CMakeLists.txt somewhere before defining targets:
include_directories(${SFML_INCLUDE_DIR})
The variable SFML_INCLUDE_DIR is populated when you successfully call find_package(SFML...).
While you're at it, you might also want to ensure to link to the proper library files in the correct order:
target_link_libraries(myTargetName ${SFML_LIBRARIES} ${SFML_DEPENDENCIES})
Again, both variables are populated automatically.
I have a project I'm writing that uses LuaJIT. I'm trying to run my project on a computer I have not run it on in a while. It used to run just fine but now when I try to run it it complains.
I have LuaJIT in my source tree, and it builds just fine. I'm using CMake to generate my make files, and as far as I can tell CMake finds the file libluajit.so, but when I run my program, I get the following error:
../build/game/game: error while loading shared libraries: libluajit-5.1.so.2: cannot open shared object file: No such file or directory
I don't know why it's looking for that version of the library instead of libluajit.so. This is Ubuntu linux for what it's worth. I can add more details if necessary, I can add more details if necessary, I'm not sure what info would be helpful to figure out happening.
Edit:
To build and link the program I have these lines in the file CMakeLists.txt (this is abbreviated a bit to just show the relevant bits)
find_package(LuaJIT REQUIRED)
set(Extern_LIBS luajit)
add_executable(proj ${proj_Sources})
target_link_libraries(proj ${Extern_LIBS})
After I run cmake on my source directory, I run make. Then to run it I just run ./proj
When you built it, the ".so" was actually a symlink to the library. Verisioned filenames and SONAMEs are used so that multiple versions of a library can coexist, preventing problems commonly found on... other operating systems whereby older software is incompatible with the newer library, and newer software is incompatible with the older library.