[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.k...@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.k...@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 > >
-- 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
