[Ada] Fix PR ada/99264

[Eric Botcazou]

> Jakub reported that for glibc 2.34 (trunk, unreleased), Richard said it was
> working for glibc 2.33 (latest release), your commit says "Fix build
> breakage with latest glibc release" (which is 2.33). What is correct?

Both I guess, mine is just a bit more forward-looking. ;-)

> The symptom
> "/usr/lib/x86_64-linux-gnu/ada/adalib/ahven/ahven-framework.ali" is obsolete
> and read-only
> looks exactly like the scenario described by the Debian Ada Policy.
> https://people.debian.org/~lbrenta/debian-ada-policy.html
> 
> Example with a simple dependency chain:
>   libahven depends on libgnat
>   ahven-tests depend on libahven
> libahven contains, in ahven-framework.ali, a checksum of each source
> it depends upon, including some libgnat sources.
> When libgnat changes, libahven must be rebuilt before ahven-tests.
> Else…
> The error above is reported when building ahven-tests.
> It mentions ahven-framework.ali from the libahven-dev package.
> It actually originates in a change in libgnat.
> 
> The Debian Ada policy requires that such dependencies are encoded in
> -dev package names so that dpkg later automatically prevents
> inconsistent sets of .ali files and related cryptic messages.
> 
> In the special case of libgnat, built by GCC, there is only one
> libgnatMAJOR package, containing the files usually expected in
> libgnatSO and libgnatALI-dev. The sources are not expected to change
> for a given MAJOR inside unstable.

The change is supposed to be binary compatible so not sure what this means.

> Assuming that the change is only required for glibc trunk (2.34), I'll
> revert that for Debian's package builds for the gcc branches. I'll see what
> to do if I still need gnat-10 when glibc 2.34 is in use.  Otoh, the patch
> could be conditional on the glibc version detected.

Too much hassle.  Please pester the glibc folks if you have any complaint.

-- 
Eric Botcazou