-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/NXP/S32DS_ARM_v2.2/S32DS/build_tools/gcc_v6.3/gcc-6.3-arm32-eabi/bin/arm-none-eabi-gcc.exe
-- Check for working C compiler: C:/NXP/S32DS_ARM_v2.2/S32DS/build_tools/gcc_v6.3/gcc-6.3-arm32-eabi/bin/arm-none-eabi-gcc.exe - broken
We are using CMake and NXP tooling, compiling it on a windows machine. The python script sets some pre conditions and adds the right flags based on on the build configuration.
What I have tried:
Change the permission for the build-wrapper and dependencies:
All of the tooling has the Full Control permission for all users
Call make directly:
Following some other posts, I tried to call make directly after calling cmake.:
build-wrapper should wrap clean build. What you describing might happen if you are not doing "clean " before building. Ao “make” command is ending up doing nothing.
What happens if you execute make without build-wrapper? does it build the entire project?
If I don’t use the wrapper, make builds the entire project normally. It is weird that the make command when using the wrapper just exits with a code. I haven’t been able to verify what the exit code means. Will check that with NXP
I’m a bit confused. You mentioned that you are trying with the raw make then you jumped to Python. Let’s try to understand what happened there.
Does the same make command lead to the project compilation without build-wrapper?
Are you executing it in the same environment with and without build-wrapper? both clean build? same command line?
can you share the full command-line output of these two commands(make sure to run them from the same directory and environment):
It does produce a build-wrapper.log file in the build/ directory. This looks the same as augustodepaula has also mentioned already in his first post.
You were right in that we needed to perform a clean. It turns out that we already receive an error when executing the cmake command.
-- The C compiler identification is GNU 6.3.1
-- The CXX compiler identification is GNU 6.3.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/NXP/S32DS_ARM_v2.2/S32DS/build_tools/gcc_v6.3/gcc-6.3-arm32-eabi/bin/arm-none-eabi-gcc.exe
-- Check for working C compiler: C:/NXP/S32DS_ARM_v2.2/S32DS/build_tools/gcc_v6.3/gcc-6.3-arm32-eabi/bin/arm-none-eabi-gcc.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.26/Modules/CMakeTestCCompiler.cmake:67 (message):
The C compiler
"C:/NXP/S32DS_ARM_v2.2/S32DS/build_tools/gcc_v6.3/gcc-6.3-arm32-eabi/bin/arm-none-eabi-gcc.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/lucophilipsen/Documents/Code/<repository>/build/CMakeFiles/CMakeScratch/TryCompile-qmvikh
Run Build Command(s):C:/Program Files/CMake/bin/cmake.exe -E env VERBOSE=1 C:/NXP/S32DS_ARM_v2.2/S32DS/build_tools/msys32/usr/bin/make.exe -f Makefile cmTC_32f0a/fast &&
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:147 (project)
When we call this script without the wrapper, everything compiles just fine. Both with a clean build and without. Also using the same command line.
We have managed to identify a situation where the make command may end with such an error code: CPP-4581
Basically, for this toolchain make behaves differently when it detects it is attached by a debugger, raising signals to let the debugger know about thread names.
The build wrapper does not expect this kind of special behavior, it does not handle the signal, and the inspected process (make) fails.
I can send you privately a tentative patched version that should fix the issue, but we have yet to decide what is the best curse of action.
Hello Alessandro, i’m facing a similar issue with the same IDE. I think this tentative patch could be useful. Is there a way to get access to this patch? Will it be available in a next release of the wrapper?