can't compile to web browser with Gitpod

[tonims1]

Is there an existing issue for this problem?

• I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Build system

Current Behavior

For a few days now when I try to compile in the web browser with Gitpod it gives me an error

Expected Behavior

be able to compile as before

Steps To Reproduce

start the web compiler with gitpod. by entering make arm-none-eabi-configure . gives an error

Version

Nightly (Please give date/commit below)

Transmitter

RadioMaster TX16S / TX16SMK2

Operating System (OS)

Windows

OS Version

windows 11

Anything else?

-- Detecting CXX compile features -.txt

[pagrey]

I think this might be related to #5794 and #5749.

You can add the flag -DUSE_UNSUPPORTED_TOOLCHAIN=ON on the line where you specify the build type to bypass this check and build the firmware at your own risk. If you run the command arm-none-eabi-gcc --version in gitpod and the result is 14.2.0 I think you'll be fine but that's just what I do.

[pfeerick]

It appears that there is a fault in the gitpod build toolchain and it has not updated to use the correct compiler, so that error is both correct and should not be bypassed. For some reason it appears to still be using the earlier / 2.10 toolchain, rather than the toolchain that is now in use in 2.11.

arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)

[tonims1]

Crec que això podria estar relacionat amb #5794 i #5749 .

Podeu afegir la marca -DUSE_UNSUPPORTED_TOOLCHAIN=ONa la línia on especifiqueu el tipus de compilació per evitar aquesta comprovació i crear el microprogramari sota el vostre propi risc. Si executeu l'ordre arm-none-eabi-gcc --versiona gitpod i el resultat és 14.2.0, crec que us anirà bé, però això és el que faig.

this works. thank you.

[pagrey]

so that error is both correct and should not be bypassed

Why? What is the reason for #5749, no issue was cited for the change. Is this an entirely theoretical issue? If it is then the commit should be reverted because it is causing real issues.

The build environment shouldn't be unnecessarily restricted without cause. If this was an effort to avoid problems then it obviously didn't work.

[gagarinlg]

Since you do not know which kind of problems we wanted to avoid, your way of expressing you opinion is uncalled for.
We had issues with certain gcc versions producing larger binaries, which do not fit on some radios. Also we are using the newlib which is provided with the arm supplied toolchain, compiled with certain options. Last but not least, we test only with the required compiler version and thus only firmware compiled with that version can be considered stable.

If you do not like our decision, use the cmake sitch and do not come to us crying when your radio crashes and you loose a model.

[pagrey]

I asked why because I wanted to know, understand the risk and because the advice not to use the flag seems to have been ignored here.

This is open source, I don't like or dislike any decision on this project. If it doesn't suit my needs then I make any change I want and move on. There's no need to make this personal, criticize people helping with the project or talk about crashing, loosing models and people crying.