JDK-8284772 - was RE: [jdk17] RFR: 8269148: Update minor GCC version in GitHub Actions pipeline

Andrew Hughes gnu.andrew at redhat.com
Thu Apr 14 17:45:00 UTC 2022


On 06:25 Wed 13 Apr     , 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

I'm happy to propose it for HEAD as well, probably next
week after the security update is out of the way. If there
are still objections, we could at least apply it to the
update versions we maintain.

Best regards,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222


More information about the build-dev mailing list