Source: gcc-14
Version: 14-20240121-1
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap
X-Debbugs-Cc: debian-cr...@lists.debian.org
Hello Matthias,
the -for-host stuff doesn't quite work for architecture cross bootstrap
yet and I'm looking into why. What initially seemed like a trivial
question turned out be a bit subtle.
Which gcc builds should emit -for-host packages?
This may sound like an obvious question initially, but looking beneath
makes it a little less obvious. It is relatively obvious that native
builds and cross builds (build!=host=target) should both emit -for-host
packages. The question becomes more interesting when you look into cross
toolchain builds.
>From an end-user pov using a cross toolchain, there is no need for
-for-host packages. They can use a built cross toolchain entirely
without these packages as -for-host packages effectively are
metapackages. If we look at e.g. src:gcc-14-cross, it builds e.g.
gcc-14-aarch64-linux-gnu, so in principle it could be emitting
gcc-14-for-host:arm64, but since host!=target, we can never include this
binary package in a .changes files nor upload it to the archive. We can
see that cross toolchain builds via src:gcc-14-cross must not include
-for-host packages. Likewise, cross-toolchain-base cannot include them.
The point where we really need -for-host packages is when we need to
satisfy Debian package dependencies in a cross build setting. In this
setting, we also need libstdc++-14-dev and others. This is not something
you get from a cross toolchain build (unless you patch in the
with_deps_on_target_arch_pkgs patch that you removed and is now
available in cross-gcc-dev). So when you need libstdc++-14-dev, you end
up building DEB_STAGE=rtlibs (or using natively built packages for your
target architecture) and when you do not need libstdc++-14-dev, you
almost certainly also won't need -for-host packages.
Quite clearly, doing both a cross toolchain build and a DEB_STAGE=rtlibs
build should result in -for-host packages and ideally should produce
them only once. Currently, the cross toolchain build produces them and
the DEB_STAGE=rtlibs build does not produce them. Given my reasoning in
the previous paragraph, it would also be plausible to emit them from
DEB_STAGE=rtlibs only.
Another aspect is the content of -for-host packages. They install their
doc directory as a symbolic link to $(p_xbase). In a cross toolchain
build (without with_deps_on_target_arch_pkgs), p_xbase ends up being
target-dependent. Hence, the symlink target in these -for-host packages
differs. While native builds and cross builds link to gcc-14-base, cross
toolchains link to gcc-14$(cross_bin_arch)-base and dpkg very much does
not like Multi-Arch: same packages to install conflicting symbolic
links.
As a result, the -for-host packages we emit from cross toolchain builds
cannot be installed concurrently with any other -for-host package
significantly defeating their purpose.
I looked into fixing this problem and the obvious thing to try is
changing the symlink targets in cross toolchain builds to also point to
gcc-14-base. As a consequence, they also depend on gcc-14-base, but a
cross toolchain build does not currently produce a gcc-14-base package
for the target architecture. If we were producing it, both the cross
toolchain build and the DEB_STAGE=rtlibs build were producing them and a
user would have to choose which one of them to use. It also means
introducing another variant of naming base packages besides p_base,
p_lbase and p_xbase which already are non-trivial to understand.
If we were moving the -for-host packages from the cross toolchain build
to the DEB_STAGE=rtlibs build, they would automatically reference the
right base package, because the runtime libraries also link their
documentation to it. On the flip side, the resulting -for-host packages
would not have satisfiable dependencies unless combining with a cross
toolchain build (or a native compiler for the target architecture), so
the DEB_STAGE=rtlibs would no longer be self-contained in a sense.
This move would not affect gcc-14-cross nor cross-toolchain-base,
because neither of them include -for-host packages (as we saw earlier).
In writing this, I am providing arguments that rather strongly suggest
that we should move them from the cross toolchain build to the
DEB_STAGE=rtlibs build, but is this really the right conclusion or am I
missing something?
In any case, I looked into prototyping this suggested move as a patch to
the gcc packaging. I am attaching a proof-of-concept of this, but I'm
not particularly fond of it as it noticeably increases the packaging
complexity. I am adding a lot of "addons" and pull a bit of code from
various debian/rules.d/binary-*.mk to a new
debian/rules.d/binary-forhost.mk such that prefixes that were only used
in a particular file are now spread to multiple. For instance, all
?_gdc_* variables were contained in debian/rules.d/binary-d.mk earlier
and are now
