(0039627)
Brad King (manager)
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 (reporter)
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 (manager)
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 (reporter)
2015-10-19 15:30

The detection with "-c" works (see attached CMakeOutput.log).

(0039644)
Brad King (manager)
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 (manager)
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 (reporter)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
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 (administrator)
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.

Issue History
Date Modified	Username	Field	Change
2015-10-17 04:52	nano	New Issue
2015-10-19 09:00	Brad King	Note Added: 0039627
2015-10-19 14:52	nano	Note Added: 0039641
2015-10-19 14:52	nano	File Added: CMakeError.log
2015-10-19 15:26	Brad King	Note Added: 0039642
2015-10-19 15:26	Brad King	Summary	PROPERTY CXX_STANDARD does not work with custom arm-none-eabi-g++ => Detecting custom arm-none-eabi-g++ compiler
2015-10-19 15:29	nano	File Added: CMakeOutput.log
2015-10-19 15:30	nano	Note Added: 0039643
2015-10-19 15:30	Brad King	Note Added: 0039644
2015-10-19 15:37	Brad King	Note Added: 0039645
2015-10-19 15:50	nano	Note Added: 0039646
2015-10-19 16:01	Brad King	Note Added: 0039648
2016-02-22 16:57	ajneu	Note Added: 0040518
2016-02-24 13:11	Brad King	Note Added: 0040536
2016-02-26 10:35	Brad King	Note Added: 0040558
2016-02-26 10:36	Brad King	Assigned To	=> Brad King
2016-02-26 10:36	Brad King	Status	new => resolved
2016-02-26 10:36	Brad King	Resolution	open => fixed
2016-02-26 10:36	Brad King	Fixed in Version	=> CMake 3.6
2016-02-26 10:36	Brad King	Target Version	=> CMake 3.6
2016-06-10 14:21	Kitware Robot	Note Added: 0041239
2016-06-10 14:21	Kitware Robot	Status	resolved => closed

Notes
(0039627) Brad King (manager) 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 (reporter) 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 (manager) 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 (reporter) 2015-10-19 15:30	The detection with "-c" works (see attached CMakeOutput.log).

(0039644) Brad King (manager) 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 (manager) 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 (reporter) 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 (manager) 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 (reporter) 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 (manager) 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 (manager) 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 (administrator) 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.

Relationships