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.