arm-none-eabi-g++ version check fails using latest available version from source

[pagrey]

Is there an existing issue for this problem?

• I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

The version check forced in #5749 for arm-none-eabi-g++ fails on distributions that build from source. The current Arm GNU Toolchain version 14.2.rel1 uses GCC source code based on version 14.2.0. I added and extra check allowing 14.2.0 as well which is based on the same source code to prevent the error on Archlinux.

If the change makes sense I'd be happy to submit a pull request. It's easy enough for me to keep the change local if in general working around other distributions isn't a priority.

Expected Behavior

No error when using the latest version of arm-none-eabi-g++ on distributions where it is built from source.

Steps To Reproduce

Attempt to build on Archlinux using the latest available version of arm-none-eabi-g++.

Version

Nightly (Please give date/commit below)

Transmitter

RadioMaster Boxer

Operating System (OS)

Linux

OS Version

Archlinux arm-none-eabi-gcc 14.2.0-1

Anything else?

No response

[pfeerick]

The current Arm GNU Toolchain version 14.2.rel1 uses GCC source code based on version 14.2.0.

Any idea why the source builds have a different version number to the released binaries? It's some form of "count from zero" nonsense, is it? 😖 Since there is no other "14.2" release, I see no real issue with it being loosened to 14.2.0, i.e. PR welcome :)

[pagrey]

Any idea why the source builds have a different version number to the released binaries?

Thanks for looking at this. I think the gcc intermediate release tag references the commit hash between what they consider a version update but does not increment the version in source which leads to this issue. PR #5813 seems to resolve it for me.

[gagarinlg]

I have an issue with changing that. The tested GCC version is the one provided by ARM. When someone wants to use a different version, there is a switch to override the check.
ARM delivers the compiler with a pre-compiled version of newlib, which we are also using.
We cannot guarantee that it is possible to generate working and stable binaries with another compiler, which was the reason to introduce that check

[pagrey]

The tested GCC version is the one provided by ARM.

The version of GCC provided by ARM is 14.2 snapshot=8-20180427, it is not a different version than the one labeled 14.2.0 when you compile from the latest source. This isn't about using a different version, it's about the same version having a different name because of how GCC labels their source code.

If this is supposed to test for the latest ARM distribution it's not a good one for the following reason. The ARM package 14.2.Rel1 includes:
Updated GCC to source code based on version 14.2.
Updated Binutils to source code based on version 2.43.
Updated GDB to source code based on version 15.
Updated Glibc to source code based on version 2.40
so even if somebody happens to have version 14.2.1 of GCC any of these other components could be wrong.

[pfeerick]

It may not be a different *version* (ok, is not), but it still reports as such when you test for the version, and more importantly, it seems the bundled newlib may be different. At the end of the day, we can either devise a way to more concretly lock this to only working the toolchain as provided by ARM, or leave it as it is, and just use the -DUSE_UNSUPPORTED_TOOLCHAIN flag... as if it is configured in any way different from how ARM configured it, it *is* unsupported. For Companion and Simulator, this isn't an issue, and we don't explicitly check for a version for that. But for the firmware, it needs to be the toolchain as provided by ARM, to ensure proper operation of the firmware. This could be the difference between properly operating firmware, and property damage and/or injury.

…

On Wed, 22 Jan 2025, 6:42 am Paul, ***@***.***> wrote: The tested GCC version is the one provided by ARM. The version of GCC provided by ARM is 14.2 snapshot=8-20180427, it is not a different version than the one labeled 14.2.0 when you compile from the latest source. This isn't about using a different version, it's about the same version having a different name because of how GCC labels their source code. If this is supposed to test for the latest ARM distribution it's not a good one for the following reason. The ARM package 14.2.Rel1 includes: Updated GCC to source code based on version 14.2. Updated Binutils to source code based on version 2.43. Updated GDB to source code based on version 15. Updated Glibc to source code based on version 2.40 so even if somebody happens to have version 14.2.1 of GCC any of these other components could be wrong. — Reply to this email directly, view it on GitHub <#5794 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ66KLRSI4JSBXMZ75YAUT2L2WKJAVCNFSM6AAAAABVKP36QOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBVGY4TKOJXGE> . You are receiving this because you commented.Message ID: ***@***.***>

[pagrey]

The platform specific scripts already specify the proper ARM toolchain. It seems to me if you are requiring specific versions then that's where this information belongs.

If somebody sets up their own build environment then I think it's up to them to insure they have the correct libraries and tools. It's unlikely you'll be able to specify or check every single tool required along with the version, there are just too many options. It seems like I have already opted out of using the recommended setup once by using an unsupported distribution, why opt out again?

Using the flag is no problem for me, that works fine but it doesn't seem like it's serving much purpose as the situation here shows.

[pagrey]

I closed the pull request, I don't think it is a solution for the issue #5749 was intended to resolve.

[pfeerick]

I don't think so, no. If you have any suggestions on how to make the tests better/more reliable toward that end goal, that would be appreciated. However, as mentioned in EdgeTX/build-edgetx#26, use of the newer / specific compiler and toolchain has not been done "on a whim". We partly need the newer toolchain for newer/later MCU support, but there are also firmware size issues (meaning some radios would become unsupported even sooner) with the older toolchains. There was more, but those are the two most visible and important reasons for end users. All testing is be done with that toolchain, hence why the use of any other is considered "unsupported", as is not the version we use in release (or in fact any build - PR or nightly) builds, so any bugs or issues that exclusively stem from that also won't be fixed (simply prioritisation of limited resources).

One additional aspect to be aware of is that make configure if run on it's own will run the configure steps for both native (companion, simulator) and firmware builds... so may fail as the version check is triggered then... but the make arm-none-eabi-configure command has been the preferred command to run since mid-2022 if you only want to configure for a firmware build, with make native-configure being the native equivalent. You can also use the -C flag with make to limit the scope of the job to arm-none-eabi or native.