I think it might make sense to take sys-devel/gcc:11 and package it as dev-lang/gdc-bootstrap or similar and have it build only GDC, then we can depend on that for bootstrapping for sys-devel/gcc[d]. Ultimately we'll need newer versions of this bootstrap package eventually to be our own build binaries or from somewhere else. Probably. But doing this would let us get a path for now which doesn't involve unmasking GCC 11.
the-horo: note that I pushed 3355cb0ab6d92d84eeff44163da5309d114726b3 earlier (and the Ada commits prior to that) which are relevant here.
Created attachment 904128 [details] gcc-13.3.1_p20240614[d] build.log gcc-13[-d] eselect'ed gdc-11 autodetected
Thank you so much for this work. I'd love to have a more robust way of bootstrapping a D compiler because the current methods involve sys-devel/gcc:11[d] which is masked or dev-lang/dmd::dlang[selfhost] which only works on amd64-glibc. I would also like the bootstrapping path not to involve user intervention, like needing to call `gcc-config` to change to gcc-11. I'm not sure if this is possible though as I'm not sure how functional is mixing gcc and gdc versions. I remember getting errors in dev-lang/ldc2::dlang when building with a lower gdc versions that the system gcc (like with gdc-13 when the system used gcc-14) but I don't remember exactly the source of these errors so they may be unrelated to our problem. Either way, with the change in 3355cb0ab6d92d84eeff44163da5309d114726b3 I do get a failure when trying to build gcc-13[d] having gcc-13[-d] and gcc-11[d] installed, with gcc-13 being the selected compiler version. With a manually eselect'ed gcc-11 it works.
(In reply to Andrei Horodniceanu from comment #3) > Thank you so much for this work. I'd love to have a more robust way of > bootstrapping a D compiler because the current methods involve > sys-devel/gcc:11[d] which is masked or dev-lang/dmd::dlang[selfhost] which > only works on amd64-glibc. > > I would also like the bootstrapping path not to involve user intervention, > like needing to call `gcc-config` to change to gcc-11. > > I'm not sure if this is possible though as I'm not sure how functional is > mixing gcc and gdc versions. I had a feeling we'd run into some issues but not giving up yet. Ada took a lot of hacks (as you can see!) but we got there. I just wanted to get the ball rolling on D and see where we landed. A bootstrap worked for me with GCC 14 using GCC 15's GDC. OK, so, the errors here for us are: """ /usr/lib/gcc/x86_64-pc-linux-gnu/11/../../../../x86_64-pc-linux-gnu/bin/ld: analyzer/diagnostic-manager.o: in function `ana::saved_diagnostic::operator==(ana::saved_diagnostic const&) const': diagnostic-manager.cc:(.text+0x96e): undefined reference to `std::__glibcxx_assert_fail(char const*, int, char const*, char const*)' /usr/lib/gcc/x86_64-pc-linux-gnu/11/../../../../x86_64-pc-linux-gnu/bin/ld: analyzer/diagnostic-manager.o: in function `ana::saved_diagnostic::supercedes_p(ana::saved_diagnostic const&) const': diagnostic-manager.cc:(.text+0x12a9): undefined reference to `std::__glibcxx_assert_fail(char const*, int, char const*, char const*)' /usr/lib/gcc/x86_64-pc-linux-gnu/11/../../../../x86_64-pc-linux-gnu/bin/ld: analyzer/diagnostic-manager.o: in function `ana::diagnostic_manager::add_diagnostic(ana::state_machine const*, ana::exploded_node*, ana::supernode const*, gimple const*, ana::stmt_finder const*, tree_node*, ana::svalue const*, ana::state_machine::state const*, std::unique_ptr<ana::pending_diagnostic, std::default_delete<ana::pending_diagnostic> >)': diagnostic-manager.cc:(.text+0x17b5): undefined reference to `std::__glibcxx_assert_fail(char const*, int, char const*, char const*)' /usr/lib/gcc/x86_64-pc-linux-gnu/11/../../../../x86_64-pc-linux-gnu/bin/ld: analyzer/diagnostic-manager.o: in function `ana::saved_diagnostic::calc_best_epath(ana::epath_finder*)': diagnostic-manager.cc:(.text+0x4d85): undefined reference to `std::__glibcxx_assert_fail(char const*, int, char const*, char const*)' /usr/lib/gcc/x86_64-pc-linux-gnu/11/../../../../x86_64-pc-linux-gnu/bin/ld: analyzer/diagnostic-manager.o: in function `ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph const&, ana::saved_diagnostic const&)': diagnostic-manager.cc:(.text+0x5f05): undefined reference to `std::__glibcxx_assert_fail(char const*, int, char const*, char const*)' /usr/lib/gcc/x86_64-pc-linux-gnu/11/../../../../x86_64-pc-linux-gnu/bin/ld: analyzer/diagnostic-manager.o:diagnostic-manager.cc:(.text._ZN3ana14dedupe_winners19handle_interactionsEPNS_18diagnostic_managerE[_ZN3ana14dedupe_winners19handle_interactionsEPNS_18diagnostic_managerE]+0x371): more undefined references to `std::__glibcxx_assert_fail(char const*, int, char const*, char const*)' follow """ I suspect one of the issues is that for >= GCC 12 hardened, we enabled _GLIBCXX_ASSERTIONS. I wonder what happens if we just try backport that to GCC 11?
Ooh: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4cb935cb69f12088975fa7f6907c6ace0580e2dd.
(In reply to Sam James from comment #4) > I just wanted to get the ball rolling on D and see where we landed. A > bootstrap worked for me with GCC 14 using GCC 15's GDC. Oh, yeah, bootstrapping GCC 13 with GGC 14's GDC worked for me as well. It's kinda the other way around one would expect bootstrapping to work but it does work. Maybe, in the future, we will hit some errors in regards to the D version being to high and introducing some errors that will prevent it to compile the old code, but that hasn't happened yet.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d1aa56b6e39f07490021e594920f4a965a968c07 commit d1aa56b6e39f07490021e594920f4a965a968c07 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-09-29 11:20:08 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-29 11:21:26 +0000 toolchain.eclass: start with oldest GDC and work upwards instead Per https://gcc.gnu.org/install/prerequisites.html """ It is strongly recommended to use an older version of GDC to build GDC. More recent versions of GDC than the version built are not guaranteed to work and will often fail during the build with compilation errors relating to deprecations or removed features. """ ... so do as I just did for GNAT. Bug: https://bugs.gentoo.org/940470 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
OK, it definitely does work with gcc-13 selected as a system compiler and using gcc-11 to bootstrap *without* hardened. Let's figure out hardened next then.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3cfc09d22608f46e66e233251cae04fc1e6c4444 commit 3cfc09d22608f46e66e233251cae04fc1e6c4444 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-09-30 01:33:52 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-30 01:51:45 +0000 profiles: unmask GCC 11 for now GCC 11 is the last version of GDC which doesn't need GDC to build, so it's useful for bootstrapping. Given the recent toolchain.eclass work, it'd be a shame to not facilitate things working Out Of The Box until we have some alternative package set up (see bug #940470). So, unmask for now as a temporary reprieve. But really, please don't use GCC 11 unless you must, as it's EOL. This reverts the following commits: * 4bb56f21a477a1cb4998bbc283be138bff483a9b * 0f5f8e27a03786959c2f151ce6381ffc4200a9e7 * 7de3c29b71c2b46a1e1581dcc24525433982d687 (Really, a lot of the value in masking old GCCs is to push people to check `gcc-config` and so on anyway, and most people will have hopefully done that by now in response to the mask a week ago. That doesn't make the mask pointless -- if anyone files a bug with GCC 11, we're going to tell them to try >= GCC 12, and package maintainers aren't expected to try make things work with < GCC 12 and so on, but it does mean unmasking doesn't do much harm.) Bug: https://bugs.gentoo.org/940470 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ea474da34fe1f904936f0f6b6e52d91364c36c95 commit ea474da34fe1f904936f0f6b6e52d91364c36c95 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-09-30 01:25:23 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-09-30 01:51:44 +0000 toolchain.eclass: unset _GLIBCXX_ASSERTIONS for stage1 with D bootstrap When bootstrapping D for >= GCC 12 - where we enable _GLIBCXX_ASSERTIONS by default for USE=hardened - using GCC 11, we run into trouble where an implementation detail of _GLIBCXX_ASSERTIONS changed: see PR104807, r12-7504-gd3a757af21ac33, and r12-7522-g4cb935cb69f120. Workaround this by just disabling _GLIBCXX_ASSERTIONS for the stage 1 compiler (where it's not particularly important anyway) when USE=hardened and we're building D. We could make this more conditional if needed but I don't think it's worth it. In fact, maybe we should do this unconditionally for a minor speed boost in building. Bug: https://gcc.gnu.org/PR104807 Bug: https://bugs.gentoo.org/940470 Signed-off-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 9 +++++++++ 1 file changed, 9 insertions(+)
