Discussion:
[CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
Thibault Genessay
9 years ago
Permalink
Hi,

I'm a long time user of CMake (and huge fan of it) but newly registered on
this list, so please forgive me if I have missed something regarding the
new 3.5 series.

I use CMake with the GCC ARM Embedded compiler (
https://launchpad.net/gcc-arm-embedded) to cross-compile my project
(Windows host, STM32 target, MinGW binutils). Like many users (all?) I had
to create a toolchain file because CMake doesn't support this
compiler/setup out of the box. I have taken inspiration from the many
Google hits and had a working setup until 3.5. This setup relied on the
CMAKE_FORCE_<lang>_COMPILER macros.

I installed 3.5 and the build broke, CMake complaining that this macro was
deprecated and should not be used because of the many improvements on the
compiler detection side. OK, so I removed the offending lines, simply
setting the CMAKE_C_COMPILER variable to the compiler's executable ... and
suddenly I remember why I did use this FORCE hack in the first place: CMake
tells me my compiler is broken because it cannot compile a test program
(undefined symbol: _exit). This is somehow correct, as I compile for bare
metal and I am providing the _exit function in my code. This is a
misunderstanding the CMAKE_FORCE_C_COMPILER works around by simply saying
"believe me, this compiler works".

Now I am left without many options: I can't use the FORCE hack, and I can't
convince CMake my compiler is OK. I am very open to redesign my toolchain
file, or use a stock one from CMake, or whatever this takes, but I simply
do not know how to proceed. Actually, I feel my current toolchain file,
although functional, is not "clean" but never had enough time to do it. Now
that it's a blocking issue, I do have time :)

I rolled back to 3.4 and things work so I'm safe for now. But I would be
very glad if somebody knew more about this specific problem, or this
compiler, or toolchain file writing in general. I would love to write a
"stock" toolchain file for this compiler but I simply do not know enough
(nor I can find enough up-to-date documentation).

Thanks for reading,
Cheers

Thibault
Chuck Atkins
9 years ago
Permalink
Hi Thibault,

Can you post your toolchain file?

- Chuck
...
Thibault Genessay
9 years ago
Permalink
[Note: this was erroneously sent off-list to Chuck only, sorry for the
noise]

Hi Chuck,

I can't really post my toolchain file for two reasons: 1) it contains
proprietary stuff and 2) I am ashamed of it.

OK, here you go. I just renamed whatever was proprietary. Please don't
shoot me, I promise my code and the other CMakeLists are better than that
:) When I read it again, I don't understand why I have implemented this
"flags reset" feature, and don't know if it actually works - but the rest
does. Anyway:

# Frobnicator 2
#
# Cross-compilation toolchain definition file using GNU Tools for ARM
Embedded Processors
# https://launchpad.net/gcc-arm-embedded
#
# This toolchain file assumes that the executable 'arm-none-eabi-gcc.exe'
is in the path.
# As you can see, it also assumes that you are running Windows. If not,
then please modify
# this file to make it smarter.
#
# It was written according to the CMake wiki page dedicated to this topic:
# http://www.vtk.org/Wiki/CMake_Cross_Compiling
# (especially important is the CMAKE_FORCE_C_COMPILER stuff, required
because
# the compiler is not able to spit out code without flags, breaking CMake's
# detection system otherwise)
#
# Copyright (c) 2015 Initrode SA

include(CMakeForceCompiler)

set(_should_set_flags FALSE)

if (NOT CMAKE_SYSTEM_NAME)

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_VERSION "frob2-r1")
set(CMAKE_SYSTEM_PROCESSOR cortex-m3)

CMAKE_FORCE_C_COMPILER(arm-none-eabi-gcc.exe GNU)
CMAKE_FORCE_CXX_COMPILER(arm-none-eabi-g++.exe GNU)

# To find the location of the toolchain, invoke the compiler asking for
the
# path to libc.a. This path is then stripped off of the lib/libc.a part
- this
# hopefully points to the root of the toolchain.
execute_process(
COMMAND ${CMAKE_C_COMPILER} -print-file-name=libc.a
OUTPUT_VARIABLE _path_to_toolchain
OUTPUT_STRIP_TRAILING_WHITESPACE
)
# Get rid of the filename
get_filename_component(_path_to_toolchain
"${_path_to_toolchain}" PATH
)
# Get rid of the trailing lib/ (or whatever the dir is)
get_filename_component(_path_to_toolchain
"${_path_to_toolchain}/.." REALPATH
)
set(INITRODE_CROSSCOMPILE_TOOLCHAIN ${_path_to_toolchain} CACHE PATH
"Path to the cross compiler toolchain")

set(_should_set_flags TRUE)
endif()

if (NOT _banner_already_printed)
message(STATUS "Cross-compiling using the gcc-arm-embedded toolchain")
message(STATUS " Toolchain location: ${_path_to_toolchain}")
message(STATUS " C/C++ compiler: ${CMAKE_C_COMPILER}")
message(STATUS "Frobnicator hardware version: ${CMAKE_SYSTEM_VERSION}")
message(STATUS " MCU variant:
${CMAKE_SYSTEM_PROCESSOR}")
set(_banner_already_printed TRUE)
endif ()

set(CMAKE_FIND_ROOT_PATH ${INITRODE_CROSSCOMPILE_TOOLCHAIN})

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

set(_flags_reset_mode "")

# This should only be used on the command line (i.e. cmake
-DINITRODE_RESET_C_CXX_FLAGS=1)
# and never put in the cache, otherwise changes in the GUI would be erased
at each cmake
# run (which is annoying behaviour to say the least)
if (INITRODE_RESET_C_CXX_FLAGS)
set(_should_set_flags TRUE)
set(_flags_reset_mode "FORCE")
endif ()

if (_should_set_flags)

# Generic flags
set(_flags "-fno-common -ffunction-sections -fdata-sections -Wall")

# CPU-specific flags
# These could go into a separate file but since we have no other
hardware target
# for the time being, it is kept here.
set(_flags "${_flags} -mcpu=cortex-m3 -march=armv7-m -mthumb
-msoft-float")

set(CMAKE_C_FLAGS "${_flags}" CACHE STRING "Flags used by the C
compiler during all build types." ${_flags_reset_mode})

# C++ flags
set(_cppflags "${_flags} -fno-rtti -fno-exceptions -std=c++11")
set(CMAKE_CXX_FLAGS "${_cppflags}" CACHE STRING "Flags used by the C++
compiler during all build types." ${_flags_reset_mode})

# Debugging flags
set(CMAKE_C_FLAGS_DEBUG "-g -D_DEBUG" CACHE STRING "Flags used by the C
compiler during debug builds.")
set(CMAKE_CXX_FLAGS_DEBUG "-g -D_DEBUG" CACHE STRING "Flags used by the
C++ compiler during debug builds.")
set(CMAKE_ASM_FLAGS_DEBUG "-g -D_DEBUG" CACHE STRING "Flags used by the
assembler during debug builds.")

# These are actually set by each target independently, until I manage
to understand
# what is generic (i.e. specific to the toolchain) and what is
target-specific.
##set(CMAKE_EXE_LINKER_FLAGS "-lc -lm -lgcc" CACHE STRING "Flags used
by the linker.")
endif ()



Cheers,
Thibault
Brad King
9 years ago
Permalink
Hi Thibault,

Thanks for trying the release candidate!
Post by Thibault Genessay
I installed 3.5 and the build broke
While CMakeForceCompiler is deprecated we think it should still work
in most cases where it worked before, just with a warning. What
actually breaks?
Post by Thibault Genessay
CMake complaining that this macro was deprecated and should
not be used because of the many improvements on the compiler
detection side.
For reference, the discussion that led to this decision was here:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500

Basically CMake now needs to detect a lot more from the compiler than
we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
We need to make the compiler detection work for everyone.
Post by Thibault Genessay
why I did use this FORCE hack in the first place: CMake tells me
my compiler is broken because it cannot compile a test program
(undefined symbol: _exit). This is somehow correct, as I compile
for bare metal and I am providing the _exit function in my code.
Does CMake at least detect the compiler id and version correctly?
Is it then only the test for working compiler that fails? Is there
something from the toolchain we can query to decide whether it can
link an executable without an extra spec file?

Thanks,
-Brad
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Vania Joloboff
9 years ago
Permalink
Hi

We have not yet moved to 3.5 but seeing this discussion, I am wondering
what we will have to do. In our project, we have several C and C++ cross
compilers and we want to compare them on selected benchmarks. We also
want to compare different compile options and different linking options.
We know for sure these cross compilers are working properly
and our technique today is roughly

CMakeForceCompiler(A)
compile benchmarks with A (and various options)
CMakeForceCCompiler(B)
compile benchmarks with B
CMakeForceCompiler(C)
compile benchmarks with C

Next, we run all the benchmarks and compare the results.

How am I supposed to do that if CMakeForceCompiler() is deprecated ?

Vania
...
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Brad King
9 years ago
Permalink
...
CMakeForceCompiler was meant for use in toolchain files. We do
not support switching compilers within a single CMakeLists.txt file
nor multiple toolchains in a single CMake run.

Can you post a more complete example of what you're trying to do?
It sounds like your sequence should be scripted externally and run
CMake multiple times with separate build trees.

-Brad
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Thibault Genessay
9 years ago
Permalink
[Note: this was erroneously sent off-list to Brad only, sorry for the noise]

Hi Brad,
Post by Brad King
Thanks for trying the release candidate!
Well, the download page is a bit nasty as when you click "download the
latest release 3.4.1" you are shown the generic download page with 3.5-rc1
at the top :)
Post by Brad King
While CMakeForceCompiler is deprecated we think it should still work
in most cases where it worked before, just with a warning. What
actually breaks?
I might just be my own stupidity. I downloaded 3.5 this morning and tried
again. I get all the warnings, but the build, in fact, succeeds. It must
have been something else that broke and I simply overlooked the actual
reason, seeing these red deprecation warnings everywhere. As it's often the
case, a night of sleep away from the keyboard is the best way to solve
issues. So the warnings are indeed still there, but the build finishes
(didn't test the firmware but I guess it's ok).
Post by Brad King
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500
Thanks for the pointer, I had not found this thread when searching for
explanations.
Post by Brad King
Basically CMake now needs to detect a lot more from the compiler than
we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
We need to make the compiler detection work for everyone.
This is a very noble objective, and I am ready to help you make this
happen. However, I expect things will be tricky for cross compilations, as
the toolchains are exotic mixes of compilers (perhaps proprietary and
seldom used) and binutils (e.g. I've tried Cygwin and MinGW - while I favor
the latter, some find the former usable ... not me).
...
In the toolchain file I posted to Chuck, I replaced the
CMAKE_FORCE_<foo>_COMPILER by set(CMAKE_<foo>_COMPILER):

#CMAKE_FORCE_C_COMPILER(arm-none-eabi-gcc.exe GNU)
#CMAKE_FORCE_CXX_COMPILER(arm-none-eabi-g++.exe GNU)
set(CMAKE_C_COMPILER arm-none-eabi-gcc.exe)
set(CMAKE_FORCE_CXX_COMPILER arm-none-eabi-g++.exe)

and tried again. I get the same error that I had yesterday. Before I post
the output, and after having reviewed my toolchain file, I now think it's
clearly a bug in it: I don't define the linker flags, so the thing cannot
link. Easy enough. However, I don't know how to solve this as I don't want
to use the fully featured newlibc (rdimon.specs IIRC) but only the nano
variant (nano.specs, and this one doesn't have _exit and other very low
level syscalls). So if I provided generic linker flags, maybe the compiler
could be detected, but then I wouldn't be able to build my firmware with
the appropriate libc (not even considering I have different linker scripts
for different binaries - for R&D tests on different hardware,
production,etc.)

So, here's what I get:

Creating build directory 'c:\dev\frob2_build_cmake3.5'
-- Cross-compiling using the gcc-arm-embedded toolchain
-- Toolchain location:
C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/arm-none-eabi
-- C/C++ compiler: arm-none-eabi-gcc.exe
-- Frob hardware version: frob2-r1
-- MCU variant: cortex-m3
-- The C compiler identification is GNU 4.9.3
-- The CXX compiler identification is unknown
-- Found Eclipse version 4.3 (Kepler)
-- Check for working C compiler:
C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe
-- Check for working C compiler:
C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe
-- broken
CMake Error at
C:/dev/local/cmake-3.5.0-rc1-win32-x86/share/cmake-3.5/Modules/CMakeTestCCompiler.cmake:61
(message):
The C compiler

"C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe"
is not able to compile a simple test program.

It fails with the following output:

Change Dir: C:/dev/frob2_build_cmake3.5/CMakeFiles/CMakeTmp



Run Build Command:"C:/MinGW/bin/mingw32-make.exe" "cmTC_331cb/fast"

C:/MinGW/bin/mingw32-make.exe -f CMakeFiles\cmTC_331cb.dir\build.make
CMakeFiles/cmTC_331cb.dir/build

mingw32-make.exe[1]: Entering directory
'C:/dev/frob2_build_cmake3.5/CMakeFiles/CMakeTmp'

Building C object CMakeFiles/cmTC_331cb.dir/testCCompiler.c.obj



C:\dev\local\gcc-arm-none-eabi-4_9-2015q3-20150921-win32\bin\arm-none-eabi-gcc.exe
-fno-common -ffunction-sections -fdata-sections -Wall -mcpu=cortex-m3
-march=armv7-m -mthumb -msoft-float -o
CMakeFiles\cmTC_331cb.dir\testCCompiler.c.obj -c
C:\dev\frob2_build_cmake3.5\CMakeFiles\CMakeTmp\testCCompiler.c

Linking C executable cmTC_331cb

C:\dev\local\cmake-3.5.0-rc1-win32-x86\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTC_331cb.dir\link.txt --verbose=1



C:\dev\local\gcc-arm-none-eabi-4_9-2015q3-20150921-win32\bin\arm-none-eabi-gcc.exe
-fno-common -ffunction-sections -fdata-sections -Wall -mcpu=cortex-m3
-march=armv7-m -mthumb -msoft-float
CMakeFiles/cmTC_331cb.dir/testCCompiler.c.obj -o cmTC_331cb



c:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/lib/armv7-m\libc.a(lib_a-exit.o):
In function `exit':

exit.c:(.text.exit+0x16): undefined reference to `_exit'

collect2.exe: error: ld returned 1 exit status

CMakeFiles\cmTC_331cb.dir\build.make:96: recipe for target 'cmTC_331cb'
failed

mingw32-make.exe[1]: *** [cmTC_331cb] Error 1

mingw32-make.exe[1]: Leaving directory
'C:/dev/frob2_build_cmake3.5/CMakeFiles/CMakeTmp'

Makefile:125: recipe for target 'cmTC_331cb/fast' failed

mingw32-make.exe: *** [cmTC_331cb/fast] Error 2



CMake will not be able to correctly generate this project.


I hope I am being clear, but this is my first cross-compilation project so
I had a hard time setting things up in the beginning.
Thanks,

Thibault
...
Brad King
9 years ago
Permalink
Post by Brad King
While CMakeForceCompiler is deprecated we think it should still work
in most cases where it worked before, just with a warning. What
actually breaks?
I downloaded 3.5 this morning and tried again. I get all the warnings,
but the build, in fact, succeeds. It must have been something else that
broke and I simply overlooked the actual reason
Good. Thanks for testing and confirming.
Post by Brad King
Basically CMake now needs to detect a lot more from the compiler than
we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
We need to make the compiler detection work for everyone.
This is a very noble objective, and I am ready to help you make this happen.
Great!
set(CMAKE_C_COMPILER arm-none-eabi-gcc.exe)
set(CMAKE_FORCE_CXX_COMPILER arm-none-eabi-g++.exe)
The second line should set CMAKE_CXX_COMPILER.
I don't define the linker flags, so the thing cannot link.
Yes, I think this is the root of the problem. Instead of "forcing"
CMake to skip checks that involve linking we should have toolchain
files provide enough information to allow linking (or at least
explicitly tell CMake not to link during try_compile as a fallback
solution). See more below.
-- The C compiler identification is GNU 4.9.3
Good.
-- The CXX compiler identification is unknown
Please check CMakeFiles/CMakeError.log to see why it was not able
to identify the C++ compiler. Maybe the above toolchain file typo
is responsible.
-- Check for working C compiler: C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe -- broken
Okay, this is what we need to get working. CMake wants to be able
to run a try_compile for the toolchain. CMakeForceCompiler was just
skipping CMake's early check for that and so could only help for
projects not using try_compile for anything.
I don't want to use the fully featured newlibc (rdimon.specs IIRC)
but only the nano variant (nano.specs, and this one doesn't have
_exit and other very low level syscalls). So if I provided generic
linker flags, maybe the compiler could be detected, but then I
wouldn't be able to build my firmware with the appropriate libc
For linking the actual binaries during your build you must have some
linker scripts. Perhaps we should provide a way for the toolchain
file to specify a linker script to use for try_compile checks. That
would then be used during the check for a working compiler, ABI check,
and later try_compile checks to allow them to work as normal but still
represent the real target platform. Might that work for this use case?

Thanks,
-Brad
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
James Crosby
9 years ago
Permalink
Hi Brad,

For context, I'm the maintainer of yotta (github: ARMmbed/yotta), a
module system primarily for cross-compiled embedded software, which
uses CMake for the build.
Post by Brad King
Basically CMake now needs to detect a lot more from the compiler than
we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.
We need to make the compiler detection work for everyone.
I'm worried that built-in compiler detection might not be possible across
the variety of cross-compilers used. In some cases, for example, the
existence of a particular compiler, or a modified version of it, might be
a secret outside of the company using it.
Post by Brad King
For linking the actual binaries during your build you must have some
linker scripts. Perhaps we should provide a way for the toolchain
file to specify a linker script to use for try_compile checks. That
would then be used during the check for a working compiler, ABI check,
and later try_compile checks to allow them to work as normal but still
represent the real target platform. Might that work for this use case?
This could work, but it may be necessary to specify arbitrary flags, and
the format of the link command not just a link script to get a link step to
succeed.

Since the link script that people are actually using to build their program
might contain assertions about the things being linked, or reference
symbols which need to have been defined, it would need to be possible
to use a different link script at this point than in the actual
CMAKE_<LANG>_LINK_X commands.

Using a dummy link command to check that linking works seems to
undermine the purpose of checking in the first place, which suggests
that perhaps it should still be possible to skip the check?

Best regards,
James





IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Brad King
9 years ago
Permalink
Post by James Crosby
Using a dummy link command to check that linking works seems to
undermine the purpose of checking in the first place, which suggests
that perhaps it should still be possible to skip the check?
For reference, this discussion has moved to the cmake-developer list:

Toolchains and CMAKE_FORCE_C_COMPILER in 3.5
https://cmake.org/pipermail/cmake-developers/2016-February/027818.html

-Brad
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Tristram, Falk
9 years ago
Permalink
Hi,

this is a nasty problem, preventing suitable compiler detection.
I can confirm it with older versions of CMake, e.g. 3.2.x. Did not recognize it has been fixed in the meanwhile.
If anyone has a suitable solution or patched CMake version, I could help testing it.

Regards,
Falk

From: CMake [mailto:cmake-***@cmake.org] On Behalf Of Thibault Genessay
Sent: Dienstag, 9. Februar 2016 15:10
To: ***@cmake.org
Subject: [CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

Hi,

I'm a long time user of CMake (and huge fan of it) but newly registered on this list, so please forgive me if I have missed something regarding the new 3.5 series.
I use CMake with the GCC ARM Embedded compiler (https://launchpad.net/gcc-arm-embedded<https://urldefense.proofpoint.com/v2/url?u=https-3A__launchpad.net_gcc-2Darm-2Dembedded&d=CwMFaQ&c=VCWpAYkS3z1bOCIxc-BPGZarCq9MRCAVxZJE051VqH8&r=Ee2S2RR_IcVA2riuzsDuYo9W0-YuR65ZmnX9oJ70u5c&m=Ly4Lf_QNoPZw7NLyJgPtadlPnK3hYtbHWzoTFvG3t2k&s=YFTH4j_hy43hY-cPXn1-edRIyxes7EcC5rXO6mAT-Eo&e=>) to cross-compile my project (Windows host, STM32 target, MinGW binutils). Like many users (all?) I had to create a toolchain file because CMake doesn't support this compiler/setup out of the box. I have taken inspiration from the many Google hits and had a working setup until 3.5. This setup relied on the CMAKE_FORCE_<lang>_COMPILER macros.
I installed 3.5 and the build broke, CMake complaining that this macro was deprecated and should not be used because of the many improvements on the compiler detection side. OK, so I removed the offending lines, simply setting the CMAKE_C_COMPILER variable to the compiler's executable ... and suddenly I remember why I did use this FORCE hack in the first place: CMake tells me my compiler is broken because it cannot compile a test program (undefined symbol: _exit). This is somehow correct, as I compile for bare metal and I am providing the _exit function in my code. This is a misunderstanding the CMAKE_FORCE_C_COMPILER works around by simply saying "believe me, this compiler works".
Now I am left without many options: I can't use the FORCE hack, and I can't convince CMake my compiler is OK. I am very open to redesign my toolchain file, or use a stock one from CMake, or whatever this takes, but I simply do not know how to proceed. Actually, I feel my current toolchain file, although functional, is not "clean" but never had enough time to do it. Now that it's a blocking issue, I do have time :)
I rolled back to 3.4 and things work so I'm safe for now. But I would be very glad if somebody knew more about this specific problem, or this compiler, or toolchain file writing in general. I would love to write a "stock" toolchain file for this compiler but I simply do not know enough (nor I can find enough up-to-date documentation).
Thanks for reading,
Cheers
Thibault
Loading...