[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dh-ada-library ftbfs with mismatching gcc/gnat versions



Source: dh-ada-library
Followup-For: Bug #992241

Hello.

(For context, see https://bugs.debian.org/992241.  This bug should be
reassigned to either gprbuild or gnat, depending on the following
discussion)

If gnat(=10), gcc(=11) and g++(=11) are installed, then
/usr/bin/gnatgcc -> gcc-10
/usr/bin/gcc     -> gcc-11
/usr/bin/g++     -> gcc-11

Unless explicitly told otherwise by the user, gprbuild assumes that
the situation above never happens, in other words that the gcc and
gnat versions match.

I have found no better option.  Which C compiler should it select for
a GPR project mixing Ada and C++ sources?

Of course, each user could explicitly select the C compiler they want
in a gprconfig file.
But in my opinion people typing 'apt install gcc gnat gprbuild' in the
stable distribution should be able to build a project without reading
the gprconfig manual.
Also, encoding a specific GCC version in every project using gprbuild
would defeat the whole purpose of unversioned symbolic links.

I consider that the affected package is gnat, because the same issue
affects a Makefile mixing objects built by the default Ada, C and C++
compilers (the fact that the error only affects complex Makefiles
during short time periods probably explain why it has never been
reported).

For a few years, gnat has managed to be in sync with gcc in stable
releases.  So, the energy invested in supporting inconsistent versions
has been almost only useful to unstable and testing.

I suggest to change our strategy:
* drop the gnatgcc symbolic link
* report a release-critical bug blocking gnat, hence all Ada packages,
  out of testing whenever gnat and gcc default versions differ.

This would reduce ourd workload without changing anything for the vast
majority of users of the stable distribution.

Any better plan is of course welcome…


Reply to: