Do you have any need for gcc-d? If yes, for what package/software?

Downstream users have raised some complaints/confusion over its disappearance.

Looking in community, I can see packages such as adrdox, appstream-generator, dcd, dfmt, dub, tilix, meson. It's also been used to bootstrap ldc and dmd D compilers if they don't exist on new ports on other distributions.

> Re-building will only succeed using gcc from archive /repos/2022/05/10/

@ibuclaw, the trouble is, it fails to build using current Arch bootstrap procedure. I also hit this during gcc-12 dev cycle. To be honest, I didn't spend much time trying to debug it. Apologies for not raising ticket upstream. It craps out here:


/build/gcc/src/gcc/gcc/d/dmd/cond.d:637:9: error: ‘object.__switch’ not found. The current runtime does not support switch cases on strings, or the runtime is corrupt.
637 | switch (ident)
| ^
make[3]: *** [/build/gcc/src/gcc/gcc/d/Make-lang.in:400: d/cond.o] Error 1


Coincidentally, while working on streamlining the current Arch toolchain bootstrap procedure, I discovered it *does* build if the first pass of gcc is built with "--disable-bootstrap". But I don't fully understand why this works. Building first pass GCC like this doesn't seem to affect overall reproducibility... but still testing....

@Toolybird, I've tried building the package in a VM, and it looks like you've shot yourself in the foot with `gdc_include_dir=/usr/include/dlang/gdc`, so the stage1 compiler is instead picking up the gcc-d 11.2 run-time sources when building stage2.

Moving the symlink to `/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/dlang/gdc` sorts things out, but you'll need a solution that doesn't involve hacking what's currently installed.

Ahh, you've nailed it. It all makes perfect sense now. I'm not sure why that was added in the first place but it does seem unwarranted. Thanks for the insight!

While we have your attention, there's been some chatter about building / packaging gdc separately from main GCC, I'm assuming similar to how it's been done in the AUR [1]. Any thoughts on this idea? I personally prefer to build it all together like other distros but I believe @freswa has been looking into various options to ease toolchain maintenance.

[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gdc-git

I suspect it was added perhaps because the ldc package installed their modules in /usr/include/d too, which would have played havoc if picked up by gdc.

The only downside to not having it included with the main gcc build is that you lose the integration between the each language driver and compiler-proper, though I imagine using gcc to handle the compilation of D sources is likely a very niche thing to do.

anything else that's needed to get gcc-d back in? or where are we currently stuck with it / can we help to get it back in?

I kicked off a VM to locally build gcc-d-12. Currently it is at stage3 of the build process.

(Edit, apparently I borked on getting the diff out of git).
(And deleting files is out of the question for unknown reasons).

Any new progress on this?