Sorry that there are many similar questions, but I do find that Googling for CMake queries always yields similar-but-not-the-same scenarios, conflicting CMake commands and so on!
I need to force my project to build 32-bit binaries because I have to link with a library which is only available as 32-bit. I diagnosed this based on error messages such as:
/usr/bin/ld: i386 architecture of input file `*external-32bit-lib*' is incompatible with i386:x86-64 output
From what I gather, I should therefore use:
set (CMAKE_CXX_FLAGS "-m32")
This does change things - I now get several errors like:
/usr/bin/ld: i386 architecture of input file `*project-output-lib*' is incompatible with i386:x86-64 output
AND still get the same errors for the external library too. I think this is because the -m32 made gcc generate 32-bit binaries, but ld is still trying for 64-bit output? Further Googling for this problem didn't give any success, so if anyone could verify that I am right and give the correct way of doing this, I would be very grateful!
Many thanks!
If you want to compile and link for 32 bit using cmake use this for creating libraries and binaries:
Creating libraries:
add_library(mylib SHARED my_source.c)
set_target_properties(mylib PROPERTIES COMPILE_FLAGS "-m32" LINK_FLAGS "-m32")
creating executables:
add_executable(mybin sources.c)
set_target_properties(mybin PROPERTIES COMPILE_FLAGS "-m32" LINK_FLAGS "-m32")
Even if this seems like extra works, I believe a proper solution is to use toolchain file in this case. Something like:
# the name of the target operating system
set(CMAKE_SYSTEM_NAME Linux)
# which compilers to use for C and C++
set(CMAKE_C_COMPILER gcc)
set(CMAKE_C_FLAGS -m32)
set(CMAKE_CXX_COMPILER g++)
set(CMAKE_CXX_FLAGS -m32)
# here is the target environment located
set(CMAKE_FIND_ROOT_PATH /usr/i486-linux-gnu )
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Then usage is simply:
$ cmake -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake /path/to/source
The important part here is that one is now able to specify a root dir path (CMAKE_FIND_ROOT_PATH) which should be used to search for third party lib. Indeed your compiler may not be smart enough to know where to search for an x86 Qt library on an x86_64 system.
Having a toolchain file allows one to specify a different one on a par compiler basis, and you should be able to tweak the option when compiling in 32bits from a windows environement.
Nowadays this is extra works since compiling 32bits from an x86_64 Linux OS is pretty much trivial, but this solution will work for other more exotic setup.
For more information on toolchain file, one can check for example:
https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/cross_compiling/Mingw
CMAKE_CXX_FLAGS only affects the C++ compiler. You probably also have to set the flag for the C compiler:
set (CMAKE_C_FLAGS "-m32")
It sounds like you did not pass m32 to LFLAGS too, or there are old obj files skulking about. Be sure to clean first.
This question is similar to yours: cmake, gcc, cuda and -m32
Use TRY_RUN command by the following source.
size.cpp:
#include <cstdlib>
int main( int argc, char** argv )
{
size_t size = sizeof(void*);
if ( size == 4 )
return 0;
return 1;
}
CMakeLists.txt:
TRY_RUN(RUN_RESULT_VAR COMPILE_RESULT_VAR ${your_temp_dir} size.cpp RUN_OUTPUT_VARIABLE IS_64_SYSTEM)
IF(IS_64_SYSTEM)
MESSAGE(FATAL_ERROR "64 compiling not allowed!")
ENDIF(IS_64_SYSTEM)
It will work on all standard compiler.
I used malat's approach and made a Toolchain file.
I have a Toolchain file that works on some Linux dists, perhaps it will give you inspiration. It may work for you as is, or you may need other ugly hacks to get other cmake scripts you rely on to work or w/e:
https://github.com/visualboyadvance-m/visualboyadvance-m/blob/master/cmake/Toolchain-cross-m32.cmake
Related
I am new to CMake and was going through the CMake documentations and tutorials. I was able to understand that the target_include_directories command is just the -I option for the compiler (gcc for me). I tried doing it adding the directories manually by using set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -I <Path>") and it worked perfectly fine!!
My CMakeLists.txt looks something like this:
cmake_minimum_required(VERSION 3.6)
project(Project VERSION 1.0 DESCRIPTION "C Project" LANGUAGES C)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -I <path-to-header>")
add_library(basic file1.c file2.c)
#target_include_directories(basic PUBLIC "path-to-header")
#target_include_directories() is commented out as CMAKE_C_FLAGS have been set
add_executable(main.out main.c)
target_link_libraries(main.out PRIVATE basic)
I wanted to know if there any similar and alternative for the target_link_libraries command using which we can pass -L and -l options to linker in CMake??
To answer your question literally: There is the variable CMAKE_EXE_LINKER_FLAGS and its specializations CMAKE_EXE_LINKER_FLAGS_<CONFIG> for certain configurations like RELEASE or DEBUG or whatever configurations you might have defined. See the CMake documentation for more.
BUT, I highly disrecommend to use these unless you need to pass a very special compiler/linker option CMake does not know about, because these are specific to your compiler.
The point of using CMake is to describe the build process independent of the concrete compiler and platform, such that you can easily switch to another one or at least update your compiler without having to refactor your build code. So, better stick with the generic target_include_directories, target_link_libraries, and similar commands as much as possible.
If you really have to use CMAKE_C_FLAGS or CMAKE_EXE_LINKER_FLAGS I'd recommend to wrap them into an if clause making sure that you are building with the expected compiler on the expected platform and put a fatal error message into the else clause to make future users aware of a possible problem.
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.
I have a cmake cross compiler toolchain file, abridged as:
set(CMAKE_SYSTEM_NAME Linux)
if( DEFINED TC_PATH )
message( STATUS " TC_PATH IS defined. ${TC_PATH}" )
else()
message( FATAL_ERROR " TC_PATH not defined." )
endif()
set(CMAKE_C_COMPILER ${TC_PATH}/usr/bin/i586-linux/i586-linux-gcc )
set(CMAKE_CXX_COMPILER ${TC_PATH}/usr/bin/i586-linux/i586-linux-g++ )
set(CMAKE_LINKER ${TC_PATH}/usr/bin/i586-linux/i586-linux-ld )
I call cmake, setting the TC_PATH as well as the toolchain file:
~/CMakeTest/output $ cmake -DTC_PATH:PATH=/opt/toolchain -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake ../
It appears cmake is invoking the toolchain file multiple times. On the first two time, the TC_PATH check succeeds, but later, after identifying the compilers, it throws an error:
-- TC_PATH IS defined. /opt/toolchain
-- TC_PATH IS defined. /opt/toolchain
-- The C compiler identification is GNU 4.9.1
-- The CXX compiler identification is GNU 4.9.1
-- Check for working C compiler: /opt/toolchain/usr/bin/i586-linux/i586-linux-gcc
CMake Error at /home/gnac/CMakeTest/toolchain.cmake:4 (message):
TC_PATH not defined.
Call Stack (most recent call first):
/home/gnac/CMakeTest/output/CMakeFiles/3.0.2/CMakeSystem.cmake:6 (include)
CMakeLists.txt:2 (project)
So, outside of setting a permanent environment variable in the shell, how I can set the TC_PATH variable via the command line so that it will be remain in context while executing the cmake generate command?
When compiling a test project, CMake does not pass variables to it by default.
There is CMAKE_TRY_COMPILE_PLATFORM_VARIABLES option for passing variables into the test project.
In order to fix your issue, this line should be put into the toolchain file:
set(CMAKE_TRY_COMPILE_PLATFORM_VARIABLES TC_PATH)
Your toolchain needs to be self-sufficient. The step that fails is a try_compile() which is not getting your cached variables.
Your toolchain file does not look like you're cross-compiling (it does not have a CMAKE_SYSTEM_NAME) so you can do one of the following (besides setting the CC and CXX environment variables as you have mentioned):
It's sufficient to give the full path to your C and/or CXX compiler (depending on which languages you enabled), CMake will detect the rest of your GNU toolchain automatically
cmake -DCMAKE_C_COMPILER:PATH=/opt/toolchain/usr/bin/i586-linux/i586-linux-gcc
-DCMAKE_CXX_COMPILER:PATH=/opt/toolchain/usr/bin/i586-linux/i586-linux-g++ ...
Add the following to your toolchain to skip the compiler tests (because not all options may be passed to it or because your compiler/linker of choice will not produce a valid executable)
set(CMAKE_C_COMPILER_WORKS 1 CACHE INTERNAL "")
set(CMAKE_CXX_COMPILER_WORKS 1 CACHE INTERNAL "")
Or just use the CMakeForceCompiler macros, but the use is "Discouraged. Avoid using this module if possible."
Use configure_file() to put the path into your toolchain file (just make sure to do it before the project() call)
Prefer find_program() if the possible paths of your toolchain are known over setting it from the outside (see e.g. here)
References
CMake FAQ: How do I use a different compiler?
how to specify new gcc path for cmake
CMake Cross Compiling
cmake: problems specifying the compiler (2)
cmake cross-compile with specific linker doesn't pass arguments to armlink
CMake: In which Order are Files parsed (Cache, Toolchain, …)?
I am sorry that I have to revive this but I'm still wondering why I need to resort to hacks like this to propagate variables to the toolchain configuration file:
...
elseif(${OS_FSFW} STREQUAL linux AND TGT_BSP)
if(NOT SOME_VARIABLE_USED_BY_TOOLCHAINFILE)
set(ENV{SOME_VARIABLE_USED_BY_TOOLCHAINFILE} "$ENV{HOME}/raspberrypi/rootfs")
else()
set(ENV{SOME_VARIABLE_USED_BY_TOOLCHAINFILE} "${SOME_VARIABLE_USED_BY_TOOLCHAINFILE}")
endif()
set(CMAKE_TOOLCHAIN_FILE
${CMAKE_CURRENT_SOURCE_DIR}/buildsystem/cmake/CrossCompileConfig.cmake
)
endif()
I mean, it works, but why is the toolchain file unable to handle variables set by the upper CMakeList properly? CMake is even able to print out variables set that way, but doing things like checking their existence does not appear to work unless they are environmental variables.
I try to build the library Teem under Windows 64bit with levmar support using cmakeGUI with generator VisualStudio10 Win64.
First off all, i built Levmar with CLAPACK and F2C. That works fine as levmar can be compiled without errors and the demo succeds.
The mysterious thing is, when i try to build teem with levmar support ON, cmake always turns it off "because it was not found" although i told cmake the path to levmar.lib.
Thats what the CmakeGUI tells me:
"warning: Turning off Teem_LEVMAR, because it wasn't found.
Configuring done"
Here is a part of my CMakeList.txt delivered with teem:
# Look for "levmar" library <http://www.ics.forth.gr/~lourakis/levmar/>
option(Teem_LEVMAR "Build Teem with levmar library support." OFF)
set(Teem_LEVMAR_LIB "")
if(Teem_LEVMAR)
find_package(LEVMAR)
if(LEVMAR_FOUND)
add_definitions(-DTEEM_LEVMAR)
set(Teem_LEVMAR_LIB ${LEVMAR_LIBRARIES})
set(Teem_LEVMAR_IPATH ${LEVMAR_INCLUDE_DIR})
else()
# We need to set this as a cache variable, so that it will show up as
# being turned off in the cache.
message("warning: Turning off Teem_LEVMAR, because it wasn't found.")
set(Teem_LEVMAR OFF CACHE BOOL "Build Teem with levmar library support." FORCE)
endif()
endif()
Has anyone an idea what happens here?
I tried the same thing with 3 different levmar.lib and different generators but unfortunately i suggest that i have to tell cmake the exact name of the library or the name levmar.lib is simply wrong.
I reported that question also to my supervisor for my thesis but he had the same problem and could not help me.
I also tried to modify the CMakeList:
#if(Teem_LEVMAR)
include_directories(${LEVMAR}/lib)
#endif()
which was originally
if(Teem_LEVMAR)
include_directories(${Teem_LEVMAR_IPATH})
endif()
but it did not help.
Why does cmake recognizes levmar.lib not as the levmar library, in fact does not accept it.
i also tried to understand why find_package(levmar) does not succeed but now i do not know any ways to make it work.
greetings,
jan luca.