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. 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 -- 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
