Hi Magnus, thanks for pointing to the original change that introduced this.
Generally I agree that the build environment should be stable and only consciously be updated to newer versions of tools. E.g. the Ubuntu Release and the gcc major version should remain stable. However, this case it is just about changing minor steppings due to vendor packaging in a scenario where pinning to a certain version could fail out of a sudden because the old vendor package is removed. My personal feeling here is that the tradeoff to unpin the package name is the better choice. As for stability of the environment I think that also the ubuntu container that is used is updated from time to time for certain patches and we usually don't recognize it. Best regards Christoph > -----Original Message----- > From: Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> > Sent: Mittwoch, 13. April 2022 12:58 > To: Langer, Christoph <christoph.lan...@sap.com>; Andrew Hughes > <gnu.and...@redhat.com>; David Holmes <david.hol...@oracle.com>; > Aleksey Shipilev <sh...@redhat.com> > Cc: build-dev@openjdk.java.net > Subject: Why we use specific compiler versions - was: Re: JDK-8284772 - was > RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions > pipeline > > 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
