<div dir="ltr">[Note: this was erroneously sent off-list to Brad only, sorry for the noise]<br><br>Hi Brad,<br><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="im">On Tue, Feb 9, 2016 at 6:02 PM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks for trying the release candidate!<span><br></span></blockquote><div><br></div></span><div>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 :) <br></div><span class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
</span>While CMakeForceCompiler is deprecated we think it should still work<br>
in most cases where it worked before, just with a warning. What<br>
actually breaks?<br></blockquote><div><br></div></span><div>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).<br></div><span class="im"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
</span>For reference, the discussion that led to this decision was here:<br>
<br>
<a href="http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500" rel="noreferrer" target="_blank">http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500</a><br></blockquote></span><div><br><div>Thanks for the pointer, I had not found this thread when searching for explanations. <br></div>
<span></span> </div><span class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Basically CMake now needs to detect a lot more from the compiler than<br>
we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.<br>
We need to make the compiler detection work for everyone.<br></blockquote><div><br></div></span><div>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).<br></div><span class="im"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>
> why I did use this FORCE hack in the first place: CMake tells me<br>
> my compiler is broken because it cannot compile a test program<br>
> (undefined symbol: _exit). This is somehow correct, as I compile<br>
> for bare metal and I am providing the _exit function in my code.<br>
<br>
</span>Does CMake at least detect the compiler id and version correctly?<br>
Is it then only the test for working compiler that fails? Is there<br>
something from the toolchain we can query to decide whether it can<br>
link an executable without an extra spec file?<br></blockquote><div><br></div></span><div>In the toolchain file I posted to Chuck, I replaced the CMAKE_FORCE_<foo>_COMPILER by set(CMAKE_<foo>_COMPILER):<br><br> #CMAKE_FORCE_C_COMPILER(arm-none-eabi-gcc.exe GNU)<br> #CMAKE_FORCE_CXX_COMPILER(arm-none-eabi-g++.exe GNU)<br> set(CMAKE_C_COMPILER arm-none-eabi-gcc.exe)<br> set(CMAKE_FORCE_CXX_COMPILER arm-none-eabi-g++.exe)<br><br></div><div>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.)<br><br>So, here's what I get:<br><br>Creating build directory 'c:\dev\frob2_build_cmake3.5'<br>-- Cross-compiling using the gcc-arm-embedded toolchain<br>-- Toolchain location: C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/arm-none-eabi<br>-- C/C++ compiler: arm-none-eabi-gcc.exe<br>-- Frob hardware version: frob2-r1<br>-- MCU variant: cortex-m3<br>-- The C compiler identification is GNU 4.9.3<br>-- The CXX compiler identification is unknown<br>-- Found Eclipse version 4.3 (Kepler)<br>-- Check for working C compiler: C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe<br>-- Check for working C compiler: C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe -- broken<br>CMake Error at C:/dev/local/cmake-3.5.0-rc1-win32-x86/share/cmake-3.5/Modules/CMakeTestCCompiler.cmake:61 (message):<br> The C compiler<br> "C:/dev/local/gcc-arm-none-eabi-4_9-2015q3-20150921-win32/bin/arm-none-eabi-gcc.exe"<br> is not able to compile a simple test program.<br><br> It fails with the following output:<br><br> Change Dir: C:/dev/frob2_build_cmake3.5/CMakeFiles/CMakeTmp<br><br><br><br> Run Build Command:"C:/MinGW/bin/mingw32-make.exe" "cmTC_331cb/fast"<br><br> C:/MinGW/bin/mingw32-make.exe -f CMakeFiles\cmTC_331cb.dir\build.make<br> CMakeFiles/cmTC_331cb.dir/build<br><br> mingw32-make.exe[1]: Entering directory<br> 'C:/dev/frob2_build_cmake3.5/CMakeFiles/CMakeTmp'<br><br> Building C object CMakeFiles/cmTC_331cb.dir/testCCompiler.c.obj<br><br><br> C:\dev\local\gcc-arm-none-eabi-4_9-2015q3-20150921-win32\bin\arm-none-eabi-gcc.exe<br> -fno-common -ffunction-sections -fdata-sections -Wall -mcpu=cortex-m3<br> -march=armv7-m -mthumb -msoft-float -o<br> CMakeFiles\cmTC_331cb.dir\testCCompiler.c.obj -c<br> C:\dev\frob2_build_cmake3.5\CMakeFiles\CMakeTmp\testCCompiler.c<br><br> Linking C executable cmTC_331cb<br><br> C:\dev\local\cmake-3.5.0-rc1-win32-x86\bin\cmake.exe -E cmake_link_script<br> CMakeFiles\cmTC_331cb.dir\link.txt --verbose=1<br><br><br> C:\dev\local\gcc-arm-none-eabi-4_9-2015q3-20150921-win32\bin\arm-none-eabi-gcc.exe<br> -fno-common -ffunction-sections -fdata-sections -Wall -mcpu=cortex-m3<br> -march=armv7-m -mthumb -msoft-float<br> CMakeFiles/cmTC_331cb.dir/testCCompiler.c.obj -o cmTC_331cb<br><br><br> 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):<br> In function `exit':<br><br> exit.c:(.text.exit+0x16): undefined reference to `_exit'<br><br> collect2.exe: error: ld returned 1 exit status<br><br> CMakeFiles\cmTC_331cb.dir\build.make:96: recipe for target 'cmTC_331cb'<br> failed<br><br> mingw32-make.exe[1]: *** [cmTC_331cb] Error 1<br><br> mingw32-make.exe[1]: Leaving directory<br> 'C:/dev/frob2_build_cmake3.5/CMakeFiles/CMakeTmp'<br><br> Makefile:125: recipe for target 'cmTC_331cb/fast' failed<br><br> mingw32-make.exe: *** [cmTC_331cb/fast] Error 2<br><br></div><div><br></div><div><br> CMake will not be able to correctly generate this project.<br><br></div></div><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra">Thanks,<br><br></div>Thibault<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 9, 2016 at 6:02 PM, Brad King <span dir="ltr"><<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Thibault,<br>
<br>
Thanks for trying the release candidate!<br>
<span class=""><br>
On 02/09/2016 09:10 AM, Thibault Genessay wrote:<br>
> I installed 3.5 and the build broke<br>
<br>
</span>While CMakeForceCompiler is deprecated we think it should still work<br>
in most cases where it worked before, just with a warning. What<br>
actually breaks?<br>
<span class=""><br>
> CMake complaining that this macro was deprecated and should<br>
> not be used because of the many improvements on the compiler<br>
> detection side.<br>
<br>
</span>For reference, the discussion that led to this decision was here:<br>
<br>
<a href="http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500" rel="noreferrer" target="_blank">http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/14410/focus=14500</a><br>
<br>
Basically CMake now needs to detect a lot more from the compiler than<br>
we can expect a caller to provide in a CMAKE_FORCE_C_COMPILER call.<br>
We need to make the compiler detection work for everyone.<br>
<span class=""><br>
> why I did use this FORCE hack in the first place: CMake tells me<br>
> my compiler is broken because it cannot compile a test program<br>
> (undefined symbol: _exit). This is somehow correct, as I compile<br>
> for bare metal and I am providing the _exit function in my code.<br>
<br>
</span>Does CMake at least detect the compiler id and version correctly?<br>
Is it then only the test for working compiler that fails? Is there<br>
something from the toolchain we can query to decide whether it can<br>
link an executable without an extra spec file?<br>
<br>
Thanks,<br>
-Brad<br>
<br>
</blockquote></div><br></div>