New Toolchain GCC 10.3.1 Not Able To Compile Simple Test Program

[Noah]

Hello,

I had been using a custom “third-party” toolchain pointed at arm-none-eabi GCC version 10.2.1 in my VisualGDB CMake project. When I saw that the SysGCC version was updated to 10.3.1 I decided to switch to that. However, this caused the following error:

——————————————-

-- Check for working C compiler: C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.07/bin/arm-none-eabi-gcc.exe - broken
CMake Error at C:/Users/<del>********</del>/AppData/Local/VisualGDB/CMake/share/cmake-3.20/Modules/CMakeTestCCompiler.cmake:66 (message):
The C compiler

"C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2021.07/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/<del>**********</del>/Documents/<del>**************</del>/build/VisualGDB/Debug/CMakeFiles/CMakeTmp

Run Build Command(s):C:/Program Files (x86)/Sysprogs/VisualGDB/ninja.exe cmTC_11bf1 && ninja: error: CMakeFiles/rules.ninja:21: expected '=', got ':'
C:/Program Files (x86)/GNU Arm Embedded Toolchain/10 2020-q4-major/bin/....
^ near here

——————————-

What’s odd is that the rules.ninja file does not seem to exist at all.

After a few hours trying different ninja versions and cmake toolchain settings without luck, I created a “third-party” toolchain that also referenced gcc version 10.3.1. Same error.

Switching back to my “third-party” toolchain which points at GCC version 10.2.1 allows everything to generate and build again.

I am using the bundled ninja.exe as referenced by $(VISUALGDB_DIR)/ninja.exe.

I am compiling for an STM32 chip with an M3 processor using the CMake system.

My VisualGDB version is 5.5R5 (build 4124).

 

I’m curious to get to the root of this issue if it’s on my end; if it’s not, then hopefully I was able to shed light on a bug.

Thank you!

• This topic was modified 2 years, 7 months ago by Noah.

Attachments:

You must be logged in to view attached files.

[Noah]

On second inspection, the rules.ninja file exists. Seems to be a lexing error with paths (think “C:”).

Trying to compile other projects with 10.3.1 also fails in the same way, and 10.2.1 also makes it work again.

[support]

Hi,

This is a known bug of some of the Windows GCC builds: due to some reason, the paths inside the .dep files end up escaped incorrectly. We updated the VisualGDB itself (i.e. MSBuild) to handle the broken paths properly a while ago, but this won’t help with the external tools like Ninja.

Generally, please try using our latest ARM toolchain. It’s built from the official GNUARM sources using the official instructions (+flags enabling support for big-endian devices), and does not have the path encoding bug (we don’t know why the official release does).

You can also try replacing the Ninja executable in the VisualGDB directory with the latest release (or updating to VisualGDB 5.6 that includes a newer version), but this may not work either.

[Noah]

Ok thank you.

For the record, the latest ARM toolchain from Sysprogs fails in the exact same way.

[support]

Oh, thanks for pointing this out. We had the same issue with the RISC-V toolchain where our toolchain build passed the tests, but the official one did not.

Our latest ARM toolchain release has fully passed our internal tests with VisualGDB 5.6, so the Ninja executable shipped with it must include a workaround for it as well. In this case, updating to it should be a safe bet.

[Author]

Posts