How to partially disabling cmake C/C++ custom compiler checking - c++

I am trying to do some crosscompilation using cmake. Some are easy with all the examples on Internet, I managed to crosscompile my library on Linux (x86 and ARM), Windows and Android. But now I would like to do it on a custom platform.
The process I need to achieve:
Sourcing my environment (this destroy all previous bash classic environment)
Compile with cmake
Execute what I want
But Cmake is testing for symbols in my custom C/C++ libraries which make my library unable to compile. The errors I have are that cmake some versions of GLIBCXX and CXXABI (no C issues) but not all of them.
Is there a way to make cmake ok with it ?
EDIT:
I tried using:
set(CMAKE_C_COMPILER_WORKS TRUE)
set(CMAKE_CXX_COMPILER_WORKS TRUE)
And with:
include(CMakeForceCompiler)
...
cmake_force_c_compiler(${ENV_PATH}/bin/${CC})
cmake_force_cxx_compiler(${ENV_PATH}/bin/${CXX})
But cmake is still checking for symbols.

Without having your environment nor the error message it's not easy to tell the actual root cause but here are two of the common causes and respective fixes:
If you don't have a complete toolchain file created for your custom environment - so CMake can't link a simple test program - you can try the relatively new (version 3.6) global CMake variable named CMAKE_TRY_COMPILE_TARGET_TYPE.
So just add the following:
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
Then CMake would just try to build a static library.
To have only the most common GCC compiler variables set and have only some basic checks, try:
SET(CMAKE_SYSTEM_NAME Generic)
See CMake Cross Compiling: Setting up the system and toolchain:
If your target is an embedded system without OS set CMAKE_SYSTEM_NAME to "Generic"
References
CMake AMRCC + custom linker
cmake cross-compile with specific linker doesn't pass arguments to armlink

Commandline:
cmake ... \
-DCMAKE_C_COMPILER_FORCED=TRUE \
-DCMAKE_CXX_COMPILER_FORCED=TRUE
or
CMakeLists.txt
...
set(CMAKE_C_COMPILER_FORCED TRUE)
set(CMAKE_CXX_COMPILER_FORCED TRUE)
...
Works for me.

Related

How to properly create a CMAKE_TOOLCHAIN_FILE script for compiling with mingw on Windows in CMake? [duplicate]

I'm just curious to know if there is a way to set up the CMake toolchain without using environment variables at all.
I like to directly call the CMake program defining the full path to CMAKE_C_COMPILER, CMAKE_CXX COMPILER, and CMAKE_MAKE_PROGRAM without anything to do with the environment variables Is it possible?
If this isn't possible then is there any way to tell CMake where to look up for further dependency if it needs or if we can provide CMake some other files to set up everything for use instead of manually setting environment variables?
Best regards.
You can set toolchain variables in a small cmake file. Then use a toolchain file with cmake call
cmake --toolchain path/to/toolchain-file.cmake <other-options>
That's equivalent of
cmake -DCMAKE_TOOLCHAIN_FILE=path/to/toolchain-file.cmake <other-options>

CMake won't select the correct C++ compiler [duplicate]

I would like to use the IAR compiler. I noticed CMake has already have a bunch of files about this compiler:
https://github.com/jevinskie/cmake/blob/master/Modules/Compiler/IAR.cmake
From what I read the common solution is to specify manually ALL the toolchain in my CMakeLists.txt:
set(CMAKE_C_COMPILER iccarm)
set(CMAKE_CPP_COMPILER iccarm)
How CMake can link these definitions with `Modules/Compiler/IAR.cmake"?
I thought I would just have to do
include("Modules/Compiler/IAR.cmake")
What is the correct way to specify my IAR compiler?
When I do
cmake .
It still tries to use gcc instead of my IAR compiler. Why?
To select a specific compiler, you have several solutions, as exaplained in CMake wiki:
Method 1: use environment variables
For C and C++, set the CC and CXX environment variables. This method is not guaranteed to work for all generators. (Specifically, if you are trying to set Xcode's GCC_VERSION, this method confuses Xcode.)
For example:
CC=gcc-4.2 CXX=/usr/bin/g++-4.2 cmake -G "Your Generator" path/to/your/source
Method 2: use cmake -D
Set the appropriate CMAKE_FOO_COMPILER variable(s) to a valid compiler name or full path on the command-line using cmake -D.
For example:
cmake -G "Your Generator" -D CMAKE_C_COMPILER=gcc-4.2 -D CMAKE_CXX_COMPILER=g++-4.2 path/to/your/source
Method 3 (avoid): use set()
Set the appropriate CMAKE_FOO_COMPILER variable(s) to a valid compiler name or full path in a list file using set(). This must be done before any language is set (ie: before any project() or enable_language() command).
For example:
set(CMAKE_C_COMPILER "gcc-4.2")
set(CMAKE_CXX_COMPILER "/usr/bin/g++-4.2")
project("YourProjectName")
The wiki doesn't provide reason why 3rd method should be avoided...
I see more and more people who set CMAKE_C_COMPILER and other compiler-related variables in the CMakeLists.txt after the project call and wonder why this approach breaks sometimes.
What happens actually
When CMake executes the project() call, it looks for a default compiler executable and determines the way for use it: default compiler flags, default linker flags, compile features, etc.
And CMake stores path to that default compiler executable in the CMAKE_C_COMPILER variable.
When one sets CMAKE_C_COMPILER variable after the project() call, this only changes the compiler executable: default flags, features all remains set for the default compiler.
AS RESULT: When the project is built, a build system calls the project-specified compiler executable but with parameters suitable for the default compiler.
As one could guess, this approach would work only when one replaces a default compiler with a highly compatible one. E.g. replacement of gcc with clang could work sometimes.
This approach will never work for replacement of cl compiler (used in Visual Studio) with gcc one. Nor this will work when replacing a native compiler with a cross-compiler.
What to do
Never set a compiler in CMakeLists.txt.
If you want, e.g., to use clang instead of defaulted gcc, then either:
Pass -DCMAKE_C_COMPILER=<compiler> to cmake when configure the project. That way CMake will use this compiler instead of default one and on the project() call it will adjust all flags for the specified compiler.
Set CC environment variable (CXX for C++ compiler). CMake checks this variable when selects a default compiler.
(Only in rare cases) Set CMAKE_C_COMPILER variable before the project() call. This approach is similar to the first one, but makes the project less flexible.
If the ways above do not work
If on setting CMAKE_C_COMPILER in the command line CMake errors that a compiler cannot "compile a simple project", then something wrong in your environment.. or you specify a compiler incompatible for chosen generator or platform.
Examples:
Visual Studio generators work with cl compiler but cannot work with gcc.
A MinGW compiler usually requires MinGW Makefiles generator.
Incompatible generator cannot be fixed in CMakeLists.txt. One need to pass the proper -G option to the cmake executable (or select the proper generator in CMake GUI).
Cross-compiling
Cross-compiling usually requires setting CMAKE_SYSTEM_NAME variable, and this setting should normally be done in the toolchain file. That toolchain file is also responsible for set a compiler.
Setting CMAKE_SYSTEM_NAME in the CMakeLists.txt is almost always an error.
You need to create a toolchain file, and use the CmakeForceCompiler module.
Here is an example toolchain file for bare-metal ARM development with IAR:
include(CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME Generic) # Or name of your OS if you have one
set(CMAKE_SYSTEM_PROCESSOR arm) # Or whatever
set(CMAKE_CROSSCOMPILING 1)
set(CMAKE_C_COMPILER iccarm) # Change the arm suffix if appropriate
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) # Required to make the previous line work for a target that requires a custom linker file
The last line is necessary because CMake will try to compile a test program with the compiler to make sure it works and to get some version information from preprocessor defines. Without this line, CMake will use add_executable() for the test program, and you will get the error "The C compiler "XXX" is not able to compile a simple test program." This is because the test program fails to link, as it doesn't have your custom linker file (I'm assuming bare-metal development since this is what IAR is usually used for). This line tells CMake to use add_library() instead, which makes the test succeed without the linker file. Source of this workaround: this CMake mailing list post.
Then, assuming that your toolchain file is named iar-toolchain.cmake, invoke CMake like this:
cmake -DCMAKE_TOOLCHAIN_FILE=iar-toolchain.cmake .
You can call cmake like this:
cmake -DCMAKE_C_COMPILER=iccarm ...
or
cmake -DCMAKE_CXX_COMPILER=...
If you don't want to use your PC's standard compiler, you have to give CMake the path to the compiler. You do this via environment variables, a toolchain file or direct definitions in the CMake command line (see e.g. CMake Error at CMakeLists.txt:30 (project): No CMAKE_C_COMPILER could be found).
Putting the compiler's name/path into your CMakeLists.txt would stop your project from being cross-platform.
CMake does check for the compiler ids by compiling special C/C++ files. So no need to manually include from Module/Compiler or Module/Platform.
This will be automatically done by CMake based on its compiler and platform checks.
References
CMake: In which Order are Files parsed (Cache, Toolchain, …)?
CMake GitLab Commit: Add support files for C, C++ and ASM for the IAR toolchain.
IAR Systems recently published a basic CMake tutorial with examples under their GitHub profile.
I like the the idea of a generic toolchain file which works seamlessly for both Windows and Linux compilers using find_program().
The following snippet will be used for when using C and can be used similarly for CXX:
# IAR C Compiler
find_program(CMAKE_C_COMPILER
NAMES icc${CMAKE_SYSTEM_PROCESSOR}
PATHS ${TOOLKIT}
"$ENV{ProgramFiles}/IAR Systems/*"
"$ENV{ProgramFiles\(x86\)}/IAR Systems/*"
/opt/iarsystems/bx${CMAKE_SYSTEM_PROCESSOR}
PATH_SUFFIXES bin ${CMAKE_SYSTEM_PROCESSOR}/bin
REQUIRED )
For ASM, I initially got puzzled with the NAMES but then I realized that the toolchain file was made that way for working with old Assemblers shipped with XLINK:
find_program(CMAKE_ASM_COMPILER
NAMES iasm${CMAKE_SYSTEM_PROCESSOR} a${CMAKE_SYSTEM_PROCESSOR}
PATHS ${TOOLKIT}
"$ENV{PROGRAMFILES}/IAR Systems/*"
"$ENV{ProgramFiles\(x86\)}/IAR Systems/*"
/opt/iarsystems/bx${CMAKE_SYSTEM_PROCESSOR}
PATH_SUFFIXES bin ${CMAKE_SYSTEM_PROCESSOR}/bin
REQUIRED )
Also, take a look at the full toolchain file. It will work automatically for "Arm" when the tools are installed on their default locations, otherwise it is just about updating the TOOLKIT variable and the compilers for all the supported languages should adjust automatically.
If your wanting to specify a compiler in cmake then just do ...
cmake_minimum_required(VERSION 3.22)
set(CMAKE_C_COMPILER "clang")
set(CMAKE_CXX_COMPILER "clang++")
Options 1 is only used if you want to specify what compiler you want to use as default for everything that you might compile on your computer. And I don't even think it would work on windows.
Option 2 would be used if you only want to use a different temporarily.
Option 3 is used if that's the compiler that should be used for that particular project. Also option 3 would be the most cross compatible.

Unit testing by CTest of Cross-compiled Project

I am developing hobby OS which is cross-compiled to other architecture than my development PC and is run in QEMU emulator.
I am trying to introduce unit testing of the source files I develop for my kernel but to let them run on my development machine rather than in QEMU on my target.
In order to cross-compile my sources, I use the toolchain file which uses my custom GCC toolchain. As coming from CMake principle of toolchain file usage, the toolchain file is set up prior to project(...) definition in my root CMakeLists.txt file.
My question is how to build my test executables for my dev machine (x86_64) using the built-in GCC while cross-compiling my kernel binary for target platform... I do not know how to set CMAKE_CXX_COMPILER / CMAKE_C_COMPILER cmake variables specifically for each use case (testing, target build)
To have a look at my particular project, please feel free to navigate here:https://gitlab.com/revolta/revolta
I would like to add test/ to my project root including selected sources from source/... and manage it somehow from my root CMakeLists.txt
Thanks in advance for any concept ideas and help! Cheers Martin
The rule is - there is one compiler per configuration. Do not try to make to use two compilers per configuration. Instead run cmake two times and configure it twice,. separately for x86 testing and separately for releasing to target build.
So write a small script (you have configure.sh anyway) (I usually write a makefile with all PHONY targets) that would run and build the project twice for two configurations:
# ./compile_and_test_your_project.sh
# build for target host
cmake -DCMAKE_TOOLCHAIN_FILE=the_toolchain -S. -B_build/crosscompiled
cmake --build _build/crosscompiled --target the_main_project_target
( cd _build/crosscompiled && ctest )
# build for native host
cmake -DCMAKE_C_FLAGS="-fsanitize=undefined -ggdb3 -O0" -S. -B_build/native
cmake --build _build/native --target only_testing_targets
( cd _build/native && ctest )
Do not set CMAKE_CROSSCOMPILING_EMULATOR inside cmake config. I advise to try to keep cmake configuration platform agnostic as much as you can and pass platform specific parts using arguments to cofiguration cmake. Such way is scalable - you may use a different toolchain and different environment with ease, or try different compiler options. Inside cmake you can see if you are crosscompiling with just if (CMAKE_CROSSCOMPILING). Also see CMAKE_CROSSCOMPILING_EMULATOR.
ps. My makefile from one of my projects that sets different CMAKE_CROSSCOMPILING_EMULATOR depending on make target.

Cmake cross compiling: finding tools

I am using a standalone toolchain made from the android ndk13b. It works fine, but to find all the tools (linker, archiver etc.) I have a quite verbose section in my toolchain file. Is there a way to make it more condensed?
SET(COMPILER_PATH "<path_to_my_llvm_directory>")
SET(CMAKE_TOOLCHAIN_PREFIX aarch64-linux-android-) #In theory should allow to find minor tools like ar and objdump, see http://stackoverflow.com/a/7032021/2436175
find_program(CMAKE_C_COMPILER clang.cmd PATH ${COMPILER_PATH})
find_program(CMAKE_CXX_COMPILER clang++.cmd PATH ${COMPILER_PATH})
find_program(CMAKE_AR ${CMAKE_TOOLCHAIN_PREFIX}ar.exe PATHS ${COMPILER_PATH})
find_program(CMAKE_RANLIB ${CMAKE_TOOLCHAIN_PREFIX}ranlib.exe PATHS ${COMPILER_PATH})
find_program(CMAKE_LINKER ${CMAKE_TOOLCHAIN_PREFIX}ld.exe PATHS ${COMPILER_PATH})
find_program(CMAKE_NM ${CMAKE_TOOLCHAIN_PREFIX}nm.exe PATHS ${COMPILER_PATH})
find_program(CMAKE_OBJCOPY ${CMAKE_TOOLCHAIN_PREFIX}objcopy.exe PATHS ${COMPILER_PATH})
find_program(CMAKE_OBJDUMP ${CMAKE_TOOLCHAIN_PREFIX}objdump.exe PATHS ${COMPILER_PATH})
find_program(CMAKE_STRIP ${CMAKE_TOOLCHAIN_PREFIX}strip.exe PATHS ${COMPILER_PATH})
What didn't work:
Not explicitly using find_program -> It finds some other tools from some other mingw toolchain I have in my path
Setting CMAKE_FIND_ROOT_PATH to ${COMPILER_PATH}. It won't even find the compiler at that point. I can workaround that by setting the compiler instead with SET(CMAKE_C_COMPILER ${COMPILER_PATH}/clang.cmd) (same for clang++), but it still doesn't find the other tools
Trying various flags with find_program, especially ONLY_CMAKE_FIND_ROOT_PATH
Note that I found find_program to be the only workaround to find the tools, because for example the following won't work:
SET(CMAKE_AR ${COMPILER_PATH}/${CMAKE_TOOLCHAIN_PREFIX}ar.exe
(The archive operation will fail and I can see from cmake-gui that the variable is not set).
The good new is that Android NDK support got a lot easier with the latest CMake 3.7 release. See Kitware Increases Android Support in CMake 3.7 and Cross Compiling for Android.
Edit: I have successfully run a test with CMake 3.7 (e.g. installed ADK to root on my Windows PC):
toolchain.cmake
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_SYSROOT "C:/android-ndk-r13b/platforms/android-24/arch-arm64")
And used e.g. the Ninja makefile generator:
> cmake -DCMAKE_TOOLCHAIN_FILE=../toolchain.cmake -G "Ninja" ..
-- Android: Targeting API '24' with architecture 'arm64', ABI 'arm64-v8a', and processor 'aarch64'
-- Android: Selected GCC toolchain 'aarch64-linux-android-4.9'
-- The C compiler identification is GNU 4.9.0
-- The CXX compiler identification is GNU 4.9.0
Simplified Toolchains in General
I've made some good experiences with minimal toolchain files and generally - if you want to specify tool paths specifically - using cached variables in the toolchain file.
See this minimal example from CMake's documentation, which would translate in your case into something like:
set(CMAKE_SYSTEM_NAME Android)
set(CMAKE_SYSTEM_PROCESSOR arm)
set(CMAKE_C_COMPILER <path_to_my_llvm_directory>/clang.cmd)
set(CMAKE_C_COMPILER_TARGET aarch64-linux-android)
set(CMAKE_CXX_COMPILER <path_to_my_llvm_directory>/clang++.cmd)
set(CMAKE_CXX_COMPILER_TARGET aarch64-linux-android)
Note that specifying CMAKE_SYSTEM_NAME is essential to enable crosscompiling.
Why specifying CMAKE_AR didn't work
Regarding your CMAKE_AR problem please note that CMake itself does use find_program() to find ar.exe. Since find_program() does cache its results, you have to prefill CMAKE_AR also as cached variable (see 0013038: cannot set CMAKE_AR when cross-compiling Fortran-only project).

Netbeans project imported from existing cmake application fails to build with filesystem error on Windows

I am attempting to import a manually-created cmake project that I had been using in a different IDE into Netbeans 8.0.2 on Windows 7. Needless to say, my cmake configuration worked fine there.
Netbeans seems to import the directory fine. I imported it in "automatic" (cmake) mode. However, when I attempt to build the project, I get a rather cryptic (Java?) error message:
Makefile:76: recipe for target 'all' failed
process_begin: CreateProcess(NULL, /C/MinGW/bin/make.exe -f CMakeFiles/Makefile2 all, ...) failed.
make (e=2): The system cannot find the file specified.
Knowing very little about Java, I am not sure how to interpret this error. The first directory (/C/MinGW/bin/make.exe) stands out to me as not being in Windows-format, but I am not sure if that's incorrect. I do indeed have a file by that name, as I copied the longer-named mingw make binary so I would only need to type "make".
Presuming this is being run in the project root, and that the first directory is formatted correctly, I don't see any problem with finding these files.
My CMakeLists.txt is:
cmake_minimum_required(VERSION 2.8.4)
set(Project_Name "Test")
set(Test_VERSION_MAJOR 1)
set(Test_VERSION_MINOR 0)
project(${Project_Name})
include_directories(
"${CMAKE_CURRENT_SOURCE_DIR}/inc"
"${CMAKE_CURRENT_SOURCE_DIR}/inc/SDL"
"C:/Users/Bakaiya/Documents/ogre/OgreMain/include"
)
file(GLOB SOURCE_FILES "${CMAKE_CURRENT_SOURCE_DIR}/src/*.cpp")
link_directories(${CMAKE_CURRENT_SOURCE_DIR} ${OPENGL_LIBRARIES})
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
add_executable(${Project_Name} ${SOURCE_FILES})
target_link_libraries(${Project_Name} SDL2main SDL2 OgreMain) #Ogre
Running the "generate makefile" command in the IDE completes without issue, but does not fix the problem. Additionally, clean fails, but "help" does work.
This is a problem within the IDE, it seems, because if I run make from the command line in the project root, it builds without issue.
Also, I fiddled with the file path mode setting under C/C++ -> Project Options, and it did nothing. Even set to absolute, what seems to be a relative path (CMakeFiles/Makefile2) is still in the failed command. I'm not sure if that option is expected to change that sort of reference or not.
What could be wrong with this imported project to cause this issue?
However, when I attempt to build the project, I get a rather cryptic (Java?) error message:
This is an error shown by netbeans to tell you, that it was unable to execute make command successfully. Usually this indicates a wrong setting of your (mingw-) tools.
Here are some points you can check:
Don't use make from mingw/bin, you have to use the one from mingw/msys/... There's a mingw make within mingw's msys folder, usually C:\<Path to MSYS>\<Version>\bin\make.exe - this bin-path must also be set in PATH environment variable! If MSys wasn't installed with your mingw installation, please install it.
Please check the tools set in Tools -> Options -> C/C++ -> Build Tools; you can test them by clicking Versions....
(If existing) Clean the CMake generated files and clean the cmake's cache. If not done yet, please use an out-of-source build as described here.
Can you build your project from terminal (without netbeans)?
The first directory (/C/MinGW/bin/make.exe) stands out to me as not being in Windows-format, but I am not sure if that's incorrect.
This is ok and intended by mingw - it uses linux / unix like paths.
Update
Which make program should I use?
Many MinGW users have a problem because they use mingw32-make.exe from
the MinGW installation. While this seems like the right choice, it
actually breaks the build. The problem is that this is a non-Posix
implementation of the Unix make program and doesn't work well at all.
In fact, thats why the MinGW people renamed it! They've also made a
FAQ entry explaining why you should not use mingw32-make.exe. Instead,
you should use the make.exe program from the MSYS package.
As of NetBeans 6.1, the Build Tools panel no longer allows a user to
select mingw32-make. If you choose a MinGW compiler collection it will
default to make in MSYS. If MSYS is not found, it will tell you no
make program has been found.
(http://wiki.netbeans.org/MinGWInCCDevelopmentPack)