MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015797CMakeCMakepublic2015-10-17 04:522016-06-10 14:21
Reporternano 
Assigned ToBrad King 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake 3.3.2 
Target VersionCMake 3.6Fixed in VersionCMake 3.6 
Summary0015797: Detecting custom arm-none-eabi-g++ compiler
DescriptionWhen the CMakeForceCompiler module is used to set a new compiler for cross compilation the CXX_STANDARD property does not work. arm-none-eabi-g++ is launched without -std=c++11. No errors or warnings are shown even though CXX_STANDARD_REQUIRED is set.
Steps To Reproducecmake_minimum_required(VERSION 3.3)
include(CMakeForceCompiler)

set(CMAKE_SYSTEM_NAME Generic)
CMAKE_FORCE_C_COMPILER(arm-none-eabi-gcc GNU)
CMAKE_FORCE_CXX_COMPILER(arm-none-eabi-g++ GNU)

project(bug)
add_executable(bug bug.cpp)
set_property(TARGET bug PROPERTY CXX_STANDARD 11)
set_property(TARGET bug PROPERTY CXX_STANDARD_REQUIRED ON)
Additional Information
TagsNo tags attached.
Relationships
Attached Fileslog CMakeError.log (1,849) 2015-10-19 14:52
https://public.kitware.com/Bug/file/5551/CMakeError.log
log CMakeOutput.log (987) 2015-10-19 15:29
https://public.kitware.com/Bug/file/5552/CMakeOutput.log
Issue History
Date ModifiedUsernameFieldChange
2015-10-17 04:52nanoNew Issue
2015-10-19 09:00Brad KingNote Added: 0039627
2015-10-19 14:52nanoNote Added: 0039641
2015-10-19 14:52nanoFile Added: CMakeError.log
2015-10-19 15:26Brad KingNote Added: 0039642
2015-10-19 15:26Brad KingSummaryPROPERTY CXX_STANDARD does not work with custom arm-none-eabi-g++ => Detecting custom arm-none-eabi-g++ compiler
2015-10-19 15:29nanoFile Added: CMakeOutput.log
2015-10-19 15:30nanoNote Added: 0039643
2015-10-19 15:30Brad KingNote Added: 0039644
2015-10-19 15:37Brad KingNote Added: 0039645
2015-10-19 15:50nanoNote Added: 0039646
2015-10-19 16:01Brad KingNote Added: 0039648
2016-02-22 16:57ajneuNote Added: 0040518
2016-02-24 13:11Brad KingNote Added: 0040536
2016-02-26 10:35Brad KingNote Added: 0040558
2016-02-26 10:36Brad KingAssigned To => Brad King
2016-02-26 10:36Brad KingStatusnew => resolved
2016-02-26 10:36Brad KingResolutionopen => fixed
2016-02-26 10:36Brad KingFixed in Version => CMake 3.6
2016-02-26 10:36Brad KingTarget Version => CMake 3.6
2016-06-10 14:21Kitware RobotNote Added: 0041239
2016-06-10 14:21Kitware RobotStatusresolved => closed

Notes
(0039627)
Brad King   
2015-10-19 09:00   
Recent discussion here:

 Re: CMakeForceCompiler (was: Regression caused by compute-default-dialect topic)
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500 [^]

identified that the CMakeForceCompiler module is no longer viable and should be deprecated. Also it was only ever meant for use in a toolchain file (CMAKE_TOOLCHAIN_FILE), not in CMakeLists.txt files.

The CMakeForceCompiler module should not be necessary for this use case. It was only ever meant for compilers that CMake could not identify. CMake should be able to identify any GNU compiler variant. Also it has learned alternative identification methods that render CMakeForceCompiler unnecessary even for its original purpose.
(0039641)
nano   
2015-10-19 14:52   
Thank you for the pointers!

If I change my script to use

set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(CMAKE_CXX_COMPILER arm-none-eabi-g++)

instead of CMakeForceCompiler cmake indeed detects that the compiler as GNU. Linking during detection fails though. This is not because of missing linker files (as described in your link) but because of missing syscall stubs for the c library (https://sourceware.org/newlib/libc.html#Syscalls [^]).

Maybe -nostdlib or similar could be usefull here.

I attached my CMakeError.log that contains the detailed error messages for the linker failure.
(0039642)
Brad King   
2015-10-19 15:26   
Re 0015797:0039641: We don't actually need to link to find the compiler id. We just do that on the first try because we don't know the compiler so we don't know its options. If that fails we try more options like "-c":

 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCCompiler.cmake;hb=v3.4.0-rc1#l80 [^]
 https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineCXXCompiler.cmake;hb=v3.4.0-rc1#l78 [^]

The detection should succeed with "-c" because the ".o" or ".obj" file will contain the needed information. Check CMakeOutput.log to see if this happens. If so then we can ignore the failure to link with default flags.
(0039643)
nano   
2015-10-19 15:30   
The detection with "-c" works (see attached CMakeOutput.log).
(0039644)
Brad King   
2015-10-19 15:30   
What may still need work is the check for working compiler and the compiler ABI detection. These were skipped by CMakeForceCompiler but need to work for full detection to take place and CXX_STANDARD to work (IIRC). The CMakeError.log file you attached shows that the test for a working compiler failed due to the missing stubs.
(0039645)
Brad King   
2015-10-19 15:37   
Re 0015797:0039644: The purpose of the "Determining if the C compiler works" step is to fail early if CMake does not know how to produce a binary with the compiler. We expect to have enough information by this point to generate one.

Assuming we were to get past these checks, how would your project's executables link correctly? Are you adding needed flags somewhere?
(0039646)
nano   
2015-10-19 15:50   
Re 0015797:0039645: My projects executable links correctly because I have a .c file that contains all needed stubs. The correct CMakeLists.txt should then be:

cmake_minimum_required(VERSION 3.3)

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(CMAKE_CXX_COMPILER arm-none-eabi-g++)

project(bug)
add_executable(bug bug.cpp syscall_stubs.c)
set_property(TARGET bug PROPERTY CXX_STANDARD 11)
set_property(TARGET bug PROPERTY CXX_STANDARD_REQUIRED ON)
(0039648)
Brad King   
2015-10-19 16:01   
Re 0015797:0039646: Okay, so CMake needs to somehow detect such cases and adjust its test projects accordingly. Even with CMakeForceCompiler the basic try_compile() command source file signature would fail currently so things like CheckSymbolExists may fail incorrectly.

All of these problems occur during try_compile() where we cannot iterate through multiple guesses like we do for the compiler id. We need to somehow identify this requirement up front from the target platform information.
(0040518)
ajneu   
2016-02-22 16:57   
Here's a possible workaround that might work for some users.

Use the following snippet, and be sure to have it AFTER the line with
project(myprojectname)

->

set(toolchain "" CACHE FILEPATH "")
if (toolchain AND EXISTS ${toolchain})
  message("==> Including toolchain_file ${toolchain}")
  include(${toolchain})
endif()


Then call cmake with -Dtoolchain=/my/path/to/toolchain_file
(0040536)
Brad King   
2016-02-24 13:11   
There is related discussion and changes proposed here:

 Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
 https://cmake.org/pipermail/cmake-developers/2016-February/027871.html [^]
(0040558)
Brad King   
2016-02-26 10:35   
The feature discussed in the thread linked by 0015797:0040536 is now implemented:

 try_compile: Add option to control type of target
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f1bd9fe [^]

With that one should be able to avoid using CMakeForceCompiler and allow the feature detection to work.
(0041239)
Kitware Robot   
2016-06-10 14:21   
This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.