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 rebuildingthere 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 coul...