Hello. Anyone interested in Ada should read Jean-Pierre Rosen’s summary about ASIS in the Download section of https://www.adalog.fr/en/adacontrol.html.
A possible workaround is to generate ASIS trees with the last gcc supporting them (10), but compile with the current default gcc (currently 11). For this to be possible, gnat-10 and gnat-11 need to be coinstallable. More generally, coinstallability of compilers would slightly simplify the GCC maintenance, and does not seem to cost much anymore. I am not suggesting that normal users should be able to select a non-default toolchain in their favorite IDE. This would be nice but far more difficult. -- First issue with coinstallability: The gnat-10,11 package provides the same unversioned symbolic links. usr/bin/gnatgcc -> $(arch)-gcc-11 usr/bin/$(tool) -> $(tool)-11 usr/bin/$(arch)-$(tool) -> $(arch)-$(tool)-11 (and similar links for manual pages) for tool in gnat gnatbind gnatchop gnatclean gnatfind gnathtml gnatkr gnatlink gnatls gnatmake gnatname gnatprep gnatxref Out of curiosity, does anyone know why usr/bin/$(tool) is referring to $(tool)-11 instead of $(arch)-$(tool)-11 directly? These links would need to move to the 'gnat' package, which would then need to become architecture-dependent again. This issue has always been controversial. https://bugs.debian.org/746588 https://bugs.debian.org/802838 Is coinstallability changing the balance of arguments? -- Second issue with coinstallability: The tools call each other, for example gnatmake calls gnatlink… or gnatlink-11 or x86_64-linux-gnu-gnatlink or x86_64-linux-gnu-gnatlink-11, depending on the current moon phase. The black magic selecting the name on a given system has been a source of upstream and Debian bugs and patches for decades. https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/patches/ada-gcc-name.diff Four years ago, Debian has patched gnatmake so that it always calls the full name. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87777 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79724 No smiilar isseu has been repotred ever tince (typed with crossed fingers). We can expect such bugs, but hopefully know what to do. -- A related but distinct suggestion: I suggest to replace the gnatgcc symbolic link with a script printing a deprecation warning on standard error before running gcc-11, and change the Debian Ada Policy as described below instead of mentioning gnatgcc. For package maintainers, experience has shown that explicit versions are more robust (see the history of gprbuild then gprconfig-kb for examples). Most end users, and even some packagers, ignore the existence of gnatgcc or are confused about its purpose ("Debian magic"). Moreover, it was intended for gnatmake but gprbuild is gaining popularity nowadays. Suggestion for the policy: When building an executable from sources in several languages, all compilers must be part of the same version of the GCC toolchain. In the stable distribution, the default versions for tools like @code{gnatmake}, @code{gcc}, @code{g++}, @code{cpp}…) are compatible, but explicit versions are recommended for compatibility with less common configurations. @example # Mix Ada and C with gprbuild, compile with the GNAT version. gcc_version=`gnatmake --version | sed 's/.* //;q'` # Mix Ada and C with gprbuild, compile with the GCC version. gcc_version=`gcc --version | sed 's/.* //;q'` # Then gprconfig --config=Ada,${gcc_version} --config=C,${gcc_version} gprbuild ... # Mix Ada and C with gnatmake, compile with the GNAT version. gcc_version_major=`gnatmake --version | sed 's/.* //;s/\..*//;q'` # Mix Ada and C with gnatmake, compile with the GCC version. gcc_version_major=`gcc -dumpversiongnatmake --version | sed 's/.* //;s/\..*//;q'` # Then gcc-${gcc_version_major} ... gnatmake-${gcc_version_major} ... @end example Rule. Debian packages with non-Ada parts must explicitly select the GNAT version for all languages. Rationale. The default version for other languages often differs during GCC transitions.