With the plugdata toolchain we are currently shipping 10-2020-q4, however we are investigating updates due to upcoming new targets and we’d like to have only a single arm-gcc to deal with.
Are there any known issues when using a newer version?
For another project I’m using 15.3.rel1 arm-none-eabi. Should this work fine with OWL as well?
IIRC, building with GCC13+ wasn’t working due to some breaking changes to cmath and freestanding mode in the compiler.
I’m not sure if that only affects firmware or patches or both. It might be resolvable by tweaking compiler flags, but I’m not sure how much overhead removing freestanding mode gives or if there’s a better solution to this issue.
Ok, good to know!
I suppose this breaking change should be immediately apparent when building a patch?
For libDaisy there were some issues with the included STM32 HAL source files and some hard to trace bugs that appeared on newer gcc (they had pinned to 10-2020-q4 for this reason), but that is resolved in the latest versions.
So I was worried about such known bugs as well, but if the main issue would be flat out compile errors then I guess I’ll just give it a try when I have time.
Yes, it was giving compile time errors.
To make things worse - math headers were not supposed to be available in freestanding mode according to any C standards. Except that they were usable and generally relied upon by many embedded projects. So things were broken by correcting that “bug”. There’s now partial support in C++ for cmath starting from C++ 26 standard, but this is irrelevant as OWL has been in deep hibernation for last couple of years.
I recall trying to build without -ffreestanding and I think it either gave some other errors or had some performance/patch size implications.
Today I tried a build with 15.3.rel1 and -ffreestanding removed and the main thing that was needed was to rerun make libs. The compile finished correctly after that.
I will try to do some testing on hardware later this week when I have time. The “performance/patch size implications” does sound a bit worrying though.
[Edit: I quickly compared with 10.2.1 builds and the OWL3 binaries are actually smaller:]
10.2.1 - 14724 Oct 15 13:50 patch.bin
15.3.rel1 - 13916 Oct 15 13:05 patch.bin
Sounds promising! Could you also check CPU load difference with some heavyweight patch? In fact, you haven’t mentioned if you checked that the patch built with newer GCC actually runs.
Rebuilding libs was required likely because of ABI changes between GCC versions, this frequently happens when upgrading to a new major compiler version.
I did mention that I’m yet to do such testing 
The past week I didn’t have time yet, but I’ll try to pick a day in the coming week to try out some of the publicly available patches on my Lich!