Why we use specific compiler versions - was: Re: JDK-8284772 - was RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions pipeline

[Magnus Ihse Bursie]

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