On 2022-04-14 19:42, Andrew Hughes wrote:
On 12:57 Wed 13 Apr , Magnus Ihse Bursie wrote:
I disagree completely. We had it this way in mainline originally, but it
was fixed in https://bugs.openjdk.java.net/browse/JDK-8256393.
Prior to this patch, it seems there were no GCC version requirements.
That's not what I'm suggesting.
What I'm suggesting is that we replace gcc-10=10.2.0-5ubuntu1~20.04
(or whatever it is now) with just gcc-10.
Is it possible to set the requirement to 10.2? That'd be okay for me,
since it matches how we check for gcc versions in configure (currently
it is at least "6.0"), and how we have traditionally described our
requirements.
Or are the only two options "just major version" or "major, minor, patch
and ubuntu release"? :(
/Magnus
That still selects a specific major version of GCC. It is between
major versions that we see new optimisations introduced, deprecations,
etc. I would certainly not suggest that we allow it to be switched
from e.g. GCC 10 to G11 behind our backs. I have dealt with such
transitions in Fedora and know the changes they bring.
What I don't see the advantage of is requiring a very specific package
version. If this was OpenJDK, it would be like asking to build 8u
with specifically 8u332-b05 rather than just 8u. I can't see that we
would do that without a very good reason. I don't see such a good
reason for requiring the same of GCC.
These two are handled differently on the GCC development side too.
Breakage is expected with the move to a new major version. This
is why three stable versions are currently being maintained [0].
If breakage were to happen between minor releases of a stable
version, however, that would be a bug. I've yet to see a case
of it happening, though of course it's possible.
As you might know, I'm not too fond of the GHA solution, since we can't
debug issues with Github's hosts. Nevertheless, many users look at the
GHA results as a way to sanity check their code. Any and all spurious
build failures is a problem then, since it will present a red marker --
even if the new code in the PR is okay.
This specific versioning is producing precisely these spurious
failures.
The reason I started digging into this was because my PR failed on
Linux x86_64. There were no code changes in the PR (I was backporting
the GHA setup to our Shenandoah fork of 8u). Having only just added
support to 8u mainline, I found this very odd. It turns out it failed
because it could no longer download the specific version of GCC. [1]
I agree GHA can be painful to debug - it took me weeks to get 8u
working in full - but it is useful for testing on architectures
and operating systems one doesn't have easy access to.
The less control we have over the build platform, the greater the
chance for odd and non-reproducible build failures. Selecting a
specific version of the compiler is a way to guarantee reproducible
build results. If the build succeeds in mainline, and I submit
correct code, chances are higher that the build also succeeds in my
PR. In contrast, if the gcc version suddenly were changed behind my
back, the mainline build might succeed, and my PR build fail, not
due to anything I've done wrong, but just due to the fact that the
compiler was switched by the Ubuntu team in the meantime. Yes, it
means a bit more annoyance when upgrading the compiler, but that
also means it is a conscious (and hopefully well tested)
choice. I'll take that any day over re-introducing more uncertainty
into an already-unstable testing procedure.
As I say, I'm not suggesting we don't select a specific version, just
that we are not *too* specific to the point we are constantly changing
the version specification every time the Ubuntu maintainer fixes a typo.
/Magnus
[0] https://gcc.gnu.org/
[1]
https://github.com/openjdk-bots/shenandoah-jdk8u/runs/5889665932?check_suite_focus=true
Thanks
