I disagree completely. We had it this way in mainline originally, but it
was fixed in https://bugs.openjdk.java.net/browse/JDK-8256393.
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.
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.
/Magnus
On 2022-04-13 08:25, Langer, Christoph wrote:
Hi Andrew,
One dummy question:
Why do we need to specify the real package name here?
If we install gcc-10, I think apt system will pick up the latest gcc-10 for us.
IIRC the intent is to keep control over the gcc version and not
randomly update whenever the distro updates. Upgrading compiler
versions for the OpenJDK is actually a very involved process when done
properly and we often find code changes need to be made, or warnings
adjusted, when a new version of the compiler is to be used. This
approach forces us to check the new version is okay before switching
over to it. At least that is the theory. :)
Cheers,
David
I'm in complete agreement with you as regards major versions of GCC. Fedora's
eager adoption of them means we often encounter these early. JDK-8282231 is
just the latest example from the introduction of GCC 12.
However, the GHA workflow in OpenJDK doesn't just depend on a major
version of GCC - which is actually contained in the Ubuntu package name of
gcc-9 or gcc-10 itself - but the full revision number, even down to local
packaging changes.
I believe this is overkill and leads to valuable time being wasted on issues
like
JDK-8283778 where the GCC version itself didn't even change at all, just the
Ubuntu version suffix.
Having just encountered this with 8u, I've filed JDK-8284772 there to just use
the package name, which includes the major GCC version. That's already how it
is depending on the x86_32 GCC, which hasn't suffered broken dependencies in
the same way as x86_64.
I have yet to see an issue be specific to a minor GCC version bump, whereas the
current setup is pretty much guaranteed to mean further fixes to the GitHub
workflow every time the Ubuntu packager produces a new build.
I'm happy to submit the change for other JDK versions if there is interest, but
I
at least don't want to be encountering this in maintaining 8u (and certainly not
having to add fixes to a release branch in rampdown, as happened recently
with 11u)
I'm in full agreement with you and can't see any reason for but just additional
trouble with hard maintenance of the GCC version suffix. I would love to see
JDK-8284772 be done in head and backported to all active update releases. I had
the same idea when doing JDK-8283778.
Best regards
Christoph
