Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#74720 - gcc-d removed from the package repository

Attached to Project: Arch Linux
Opened by ibuclaw (ibuclaw) - Thursday, 12 May 2022, 15:04 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To freswa (frederik)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No

Details

Description: As part of the upgrade to version 12.1

https://github.com/archlinux/svntogit-packages/commit/6ebddb843f621263f4ce6e5a8b2b6856f337c218

Steps to reproduce:

pacman -S gcc-d

Steps to fix:

Mostly revert svn@444777, then apply proper fix for upgrading to gcc 12.1.0-1

diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index 2dc218c..c19d018 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -19,6 +19,7 @@ makedepends=(
binutils
doxygen
gcc-ada
+ gcc-d
git
lib32-glibc
lib32-gcc-libs

Re-building will only succeed using gcc from archive /repos/2022/05/10/.
This task depends upon

Comment by freswa (frederik) - Thursday, 12 May 2022, 16:59 GMT
Do you have any need for gcc-d? If yes, for what package/software?
Comment by ibuclaw (ibuclaw) - Thursday, 12 May 2022, 17:14 GMT
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.
Comment by Toolybird (Toolybird) - Thursday, 12 May 2022, 22:46 GMT
> 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....
Comment by ibuclaw (ibuclaw) - Friday, 13 May 2022, 09:15 GMT
@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.
Comment by Toolybird (Toolybird) - Saturday, 14 May 2022, 01:46 GMT
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
Comment by ibuclaw (ibuclaw) - Saturday, 14 May 2022, 21:17 GMT
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.

Loading...