[CMake] Toolchains and CMAKE_FORCE_C_COMPILER in 3.5

[Thibault Genessay]

[Note: this was erroneously sent off-list to Brad only, sorry for the noise]

Hi Brad,


On Tue, Feb 9, 2016 at 6:02 PM, Brad King <brad.king at kitware.com> wrote:

> 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 :)


> 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).


> For reference, the discussion that led to this decision was here:
>
>
> 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.


> 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).

> 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?
>

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

On Tue, Feb 9, 2016 at 6:02 PM, Brad King <brad.king at kitware.com> wrote:

> Hi Thibault,
>
> Thanks for trying the release candidate!
>
> On 02/09/2016 09:10 AM, Thibault Genessay wrote:
> > 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?
>
> > 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.
>
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20160210/defdf200/attachment.html>