commit: e23d5c3ac3f48e28784350597cc888e4cea6bf6a
Author: Eli Schwartz <eschwartz <AT> gentoo <DOT> org>
AuthorDate: Tue Sep 2 19:25:54 2025 +0000
Commit: Eli Schwartz <eschwartz <AT> gentoo <DOT> org>
CommitDate: Tue Sep 2 20:05:19 2025 +0000
URL: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e23d5c3a
toolchain.eclass: ada/d: bdepend on ${PN}:${SLOT} only as a last resort
In general, there are *preferred* versus *workable* bootstrap compilers,
and it is *preferred* to build ${lang} with an already built copy of
that compiler, e.g. to get bugfixes and so on. So, for iteration order
when setting up the compilation environment, we prefer our own SLOT, if
multiple bootstrap compilers are available after `src_*` phases start
running.
As a separate matter, the dependency merge graph must pull in at least
one *workable* compiler, and it would be nice if it is a *preferred*
one. Portage solves for dependencies favoring leftmost if it is
necessary to merge an additional dependency. So, ordering from
most-preferred to least-preferred is plausibly reasonable.
Problem: given an installed *workable* but least-preferred compiler,
triggering autounmask of USE=ada causes portage to ignore a *workable*
compiler if the leftmost dependency is already in the merge graph. It
then reports a cycle, where the current package to build depends on
itself:
```
* Error: circular dependencies:
(sys-devel/gcc-14.3.0:14/14::gentoo, ebuild scheduled for merge) depends on
(sys-devel/gcc-14.3.0:14/14::gentoo, ebuild scheduled for merge) (buildtime)
```
It turns out, the order in the any-of group matters. If:
- item 1 is ${PN}:${SLOT}
- item 2 is <${PN}-${SLOT}
- item 3 is installed (ada-bootstrap)
The merge graph wants to build item 1, item 2 would build a ton of
versions and eventually need item 3, item 3 simply works without fuss.
But item 1 *cannot* be uninstalled, yet still get merged in this
transaction to satisfy the deps. And if it is already installed, we
don't need leftmost-associativity to force the preferred compiler to be
merged for building excellent machine code.
Conversely, if item 1 is moved to the end, portage... doesn't try to
autounmask item 2 (now item 1), even if item 3 (ada-bootstrap) is *not*
installed. Although without autounmasking, if "sys-devel/gcc ada" is in
package.use, it does build a large chain of gcc[ada]'s, since it can and
is leftmost.
But for autounmask, instead, it installs item 3 (ada-bootstrap) if
necessary, since it can do so without further autounmask. The incorrect
cycle is broken.
Make this change, because it only affects cycle-breaking and doesn't
affect iteration order in src_configure.
Bug: https://bugs.gentoo.org/962273
Acked-by: Sam James <sam <AT> gentoo.org>
Signed-off-by: Eli Schwartz <eschwartz <AT> gentoo.org>
eclass/toolchain.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index b54f78320f02..9e79d3de9f28 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -422,9 +422,9 @@ if [[ ${PN} != gnat-gpl ]] && tc_has_feature ada ; then
BDEPEND+="
ada? (
|| (
- sys-devel/gcc:${SLOT}[ada]
<sys-devel/gcc-${SLOT}[ada]
<dev-lang/ada-bootstrap-$((${SLOT} + 1))
+ sys-devel/gcc:${SLOT}[ada]
)
)
"
@@ -432,9 +432,9 @@ if [[ ${PN} != gnat-gpl ]] && tc_has_feature ada ; then
BDEPEND+="
ada? (
|| (
- sys-devel/gcc:${SLOT}[ada]
<sys-devel/gcc-${SLOT}[ada]
<dev-lang/ada-bootstrap-${SLOT}
+ sys-devel/gcc:${SLOT}[ada]
)
)
"
@@ -447,7 +447,7 @@ if tc_has_feature d && tc_version_is_at_least 12.0 ; then
# D in 12+ is self-hosting and needs D to bootstrap.
# TODO: package some binary we can use, like for Ada
# bug #840182
- BDEPEND+=" d? ( || ( sys-devel/gcc:${SLOT}[d(-)]
<sys-devel/gcc-${SLOT}[d(-)] <sys-devel/gcc-12[d(-)] ) )"
+ BDEPEND+=" d? ( || ( <sys-devel/gcc-${SLOT}[d(-)]
<sys-devel/gcc-12[d(-)] sys-devel/gcc:${SLOT}[d(-)] ) )"
fi
if tc_has_feature rust && tc_version_is_at_least 14.1 ; then
