Only 6 releases and 2.5 years behind

Believe it or not, that's actually a pretty up-to-date devkit I was running (by my standards) when I encountered a weird GCC bug that would turn a for loop into an endless one. I'm not super-hot about upgrading the toolchain while I just managed to have all my tools working again, but it should be safe to give them a try, at least.

There is at least one trick I'd have to fix or revert: I tried to override the _jp2uc function to save some room in the binary, but with devkitARM release 54, the trick doesn't work anymore. (well, the trick saves 14K. It wouldn't be such a big deal to drop it).

/opt/devkitpro/devkitARM/lib/gcc/arm-none-eabi/10.1.0/../../../../arm-none-eabi/bin/ld: /opt/devkitpro/devkitARM/lib/gcc/arm-none-eabi/10.1.0/../../../../arm-none-eabi/lib/thumb/libg.a(lib_a-jp2uc.o): in function `_jp2uc': (.text._jp2uc+0x0): multiple definition of `_jp2uc'; .//outnds/Demo/shrink.o:.//Demo/source/shrink.cpp:22: first defined here collect2: error: ld returned 1 exit status .//common.mk:360: recipe for target './/Demo/Demo.elf' failed 

That trick is based on the idea that symbols from libraries are weak, and thus can be overridden from the linking application if the application decides so. Maybe that assumption doesn't hold anymore ?

• apart from that trick, no breaking errors occured while rebuilding
• there is now V=1 support in ds_rules. I'll have to check to what extent that allows common.mk to be simplified.
• Both LEDS and SEDS seems to work with the new release.
• I couldn't reproduce the odd bug with latest gcc.

Note: I had tried to solve an issue with the editor getting stuck when using that Zap! command since early 2019, which is in the middle of the "devkitpro update" started in September 2018.

It's not that it crashes when we hit 'Zap!' on the palette windows: the code stalls. That's not helping to track where the bug is, of course. On alternate palettes, it doesn't it keeps working (on emulator) but extremely slowly... sometimes.

The amount of steps performed during this operation is too high to make step-by-step debugging in desmume any practical. And when it hangs, it is in the middle of nowhere, with no code to execute...

It also explains why attempts to use natively-compiled code to unit-test the issue kept useless.