[Pkg-electronics-devel] Bug#1096682: outlook on gcc-sh-elf FTBFS with GCC 15 as host compiler

[John Scott]

I have been experimenting with a lot of structural changes to gcc-sh-elf privately, but this should not block fixing this release-critical issue. Hereafter I'll focus on that.The gcc-sh-elf source package builds a toolchain using GCC 13, Newlib, and GDB (just for its simulator). I don't know what the timeline for GCC 13 removal is as I write this but if I could have just a couple more weeks for the following to work itself out, a jump from GCC 13 to GCC 15 (for the target) would be ideal. So supposing the build-dep on gcc-13-source is fine for the very near future, the host (Debian) compiler switching to GCC 15 is what's exposing this issue.

This is an issue in the gdb-source version currently in unstable. The SuperH simulator code doesn't use genuine function prototypes for certain function pointers, so GCC 15 makes the C23-ish assumption that foo() is the same as foo(void), which causes an error here. In my message from April I referred to this being fixed in upstream Git long ago, and finally with gdb-source=17.0.50.20250905-1~exp1 being in experimental, this issue can be solved, except for the following obstacles:
• At least when trying to use GCC 15 for the target too, GCC and GDB clash over the contents of include/dwarf2.h because they have different versions. The archive in gdb-source messes up the file timestamps so there's no way *in general* to tell whose version should win. I filed #1114483 to see that timestamp issue fixed and detective work is ongoing, but even with that problem out of the way, we're still dependent on gdb-source from experimental. Unless a new upstream GDB release is made that works its way into unstable, this doesn't get us anywhere in the near-term.
👉 However if we defer using GCC 15 for the target, this whole header file clash will cease to matter.

So even if we play things super safe using GCC 13 for the target (if that's okay; I'll ask in #1092657 that Matthias Klose filed to wean gcc-sh-elf off of it), we're probably still in trouble without a fresh GDB in unstable, because GCC 15 is the host compiler by default no matter what and that's what is causing the build error. I'll have to examine timelines but here is a quicker-fix option:
• Patch the GDB/simulator sources ourselves for this very small issue, maybe by just getting the upstream commit; putting logic in gcc-sh-elf to ignore the patch already appearing applied would help compatibility with GDB when it gets updated as well. In other words, we can do GDB patching right in gcc-sh-elf to cope with all relevant GDB versions. Because the FTBFS errors come about in this SuperH-specific code, that's reasonable enough to compensate for hideousness.

So, yeah. There's a lot of moving parts here. I'm going to go take a nap and eat some soup (in that order, sequentially), and I'll have a solution picked out Soon™. This is surmountable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20250906/3a582d46/attachment-0001.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7750 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20250906/3a582d46/attachment-0001.p7s>