too long lines were shrinked: Compiling /var/tmp/portage/dev-java/openjdk-8.382_p05/work/jdk8u-jdk8u382-ga/hotspot/src/share/vm/adlc/arena.cpp rm -f ../generated/adfiles/arena.o /usr/lib/llvm/17/bin/clang++ -DLINUX -D_GNU_SOURCE -DAMD64 -I/var/tmp/portage/dev-java/openjdk-8.382_p05/work/jdk8u-jdk8u382-ga/hotspot/src/share/vm/prims -I/var/tmp/portage/dev-java/openjdk-8.382_p05/work/jdk8u-jdk8u382-ga/hotspot/src/share/vm -I/var/tmp/portage/dev-java/openjdk-8.382_p05/work/jdk8 Compiling /var/tmp/portage/dev-java/openjdk-8.382_p05/work/jdk8u-jdk8u382-ga/hotspot/src/share/vm/adlc/dfa.cpp rm -f ../generated/adfiles/dfa.o /usr/lib/llvm/17/bin/clang++ -DLINUX -D_GNU_SOURCE -DAMD64 -I/var/tmp/portage/dev-java/openjdk-8.382_p05/work/jdk8u-jdk8u382-ga/hotspot/src/share/vm/prims -I/var/tmp/portage/dev-java/openjdk-8.382_p05/work/jdk8u-jdk8u382-ga/hotspot/src/share/vm -I/var/tmp/portage/dev-java/openjdk-8.382_p05/work/jdk8 /var/tmp/portage/dev-java/openjdk-8.382_p05/work/jdk8u-jdk8u382-ga/hotspot/src/share/vm/adlc/arena.cpp:82:3: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] 82 | register Chunk *k = _first; | ^~~~~~~~ ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_desktop_systemd_merged_usr-20231125-195722 ------------------------------------------------------------------- CC=clang CXX=clang++ gcc-config -l: [1] x86_64-pc-linux-gnu-10 [2] x86_64-pc-linux-gnu-13 * clang/llvm (if any): clang version 17.0.5 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/17/bin Configuration file: /etc/clang/x86_64-pc-linux-gnu-clang.cfg /usr/lib/llvm/17 17.0.5 Python 3.11.6 Available Rust versions: [1] rust-bin-1.73.0 * GENTOO_VM=openjdk-bin-8 CLASSPATH="" JAVA_HOME="/opt/openjdk-bin-8.382_p05" JAVACFLAGS="-source 8 -target 8" COMPILER="" The following VMs are available for generation-2: 1) OpenJDK 17.0.8.1_p1 [openjdk-17] 2) OpenJDK 21.0.1_p12 [openjdk-21] 3) Eclipse Temurin JDK 17.0.8.1_p1 [openjdk-bin-17] *) Eclipse Temurin JDK 21.0.1_p12 [openjdk-bin-21] 5) Eclipse Temurin JDK 8.382_p05 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-17 [2] openjdk-21 [3] openjdk-bin-8 [4] openjdk-bin-17 [5] openjdk-bin-21 system-vm php cli (if any): go version go1.21.4 linux/amd64 HEAD of ::gentoo commit 1090f05a895d959376906e780d4cd2421d330d36 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Mon Nov 27 01:32:01 2023 +0000 2023-11-27 01:32:01 UTC emerge -qpvO dev-java/openjdk [ebuild R ] dev-java/openjdk-21.0.1_p12 USE="alsa cups source (system-bootstrap) (-big-endian) -debug -doc -examples -headless-awt (-javafx) -jbootstrap -lto (-selinux) -systemtap"
Created attachment 875809 [details] emerge-info.txt
Created attachment 875810 [details] dev-java:openjdk-8.382_p05:20231127-031910.log
Created attachment 875811 [details] emerge-history.txt
Created attachment 875812 [details] environment
Created attachment 875813 [details] etc.clang.tar.xz
Created attachment 875814 [details] etc.portage.tar.xz
Created attachment 875815 [details] logs.tar.xz
Created attachment 875816 [details] qlist-info.txt
Created attachment 875817 [details] temp.tar.xz
Created attachment 875818 [details] var.tmp.clang.tar.xz
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=250d2f45f958ccb2a4e3c437d396b88f5d3bd59e commit 250d2f45f958ccb2a4e3c437d396b88f5d3bd59e Author: Sam James <sam@gentoo.org> AuthorDate: 2024-03-06 12:36:46 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-06 12:42:18 +0000 dev-java/openjdk: add 8.402_p06 * Fix various modern C issues - all by backporting parts of later JDK 11/17/21 patches. * cgroup2 issues: Assuming bug #926247 affects the source build too, but not verified, so tagging that. * Drop stale -fcommon workaround (bug #850505). * Build with -std=gnu++14 because of -Wregister for Clang 17+ compat (bug #918655). (Part of the build uses -std=gnu++98 but not all of it.) Bug: https://bugs.gentoo.org/926247 Closes: https://bugs.gentoo.org/850505 Closes: https://bugs.gentoo.org/874621 Closes: https://bugs.gentoo.org/918655 Signed-off-by: Sam James <sam@gentoo.org> dev-java/openjdk/Manifest | 1 + ...penjdk-8.402_p06-0001-Fix-Wint-conversion.patch | 41 ++++ ..._p06-0002-Fix-Wincompatible-pointer-types.patch | 48 ++++ ...02_p06-0003-Fix-negative-value-left-shift.patch | 38 ++++ ...openjdk-8.402_p06-0004-Fix-misc.-warnings.patch | 61 ++++++ dev-java/openjdk/openjdk-8.402_p06.ebuild | 244 +++++++++++++++++++++ 6 files changed, 433 insertions(+)
> * Build with -std=gnu++14 because of -Wregister for Clang 17+ compat > (bug #918655). > (Part of the build uses -std=gnu++98 but not all of it.) This seems a rather drastic fix for what appears to be https://github.com/openjdk/jdk8u-dev/pull/357 I'm also not aware of anyone building 8u with clang. This seems risky and it would be preferable to help us look into supporting this upstream, rather than piling up local patches in the ebuild. The 8u source code is very old (10+ years now) and is not really intended to be built to modern C++ standards. Hence why we added gnu++98 as an option rather than making all manner of source code changes.
(In reply to Andrew John Hughes from comment #12) > > * Build with -std=gnu++14 because of -Wregister for Clang 17+ compat > > (bug #918655). > > (Part of the build uses -std=gnu++98 but not all of it.) > > This seems a rather drastic fix for what appears to be > https://github.com/openjdk/jdk8u-dev/pull/357 > > I'm also not aware of anyone building 8u with clang. > > This seems risky and it would be preferable to help us look into supporting > this upstream, rather than piling up local patches in the ebuild. I'm not sure it's that risky. Both GCC and Clang default to -std=gnu++17 right now. We can try -std=gnu++98 if the whole thing builds with it, though. It was only being used partially when I looked before.
(In reply to Sam James from comment #13) > (In reply to Andrew John Hughes from comment #12) > > > * Build with -std=gnu++14 because of -Wregister for Clang 17+ compat > > > (bug #918655). > > > (Part of the build uses -std=gnu++98 but not all of it.) > > > > This seems a rather drastic fix for what appears to be > > https://github.com/openjdk/jdk8u-dev/pull/357 > > > > I'm also not aware of anyone building 8u with clang. > > > > This seems risky and it would be preferable to help us look into supporting > > this upstream, rather than piling up local patches in the ebuild. > > I'm not sure it's that risky. Both GCC and Clang default to -std=gnu++17 > right now. > I'm aware of that but I'm not sure how it changes the situation. 8u was developed against older versions of GCC that defaulted to -std=gnu++98. It is a stable JDK and we don't tend to backport changes just to silence compiler warnings, especially if there is a safer alternative. When GCC 6 started using a newer default standard, I added the configure check to OpenJDK 8 which explicitly sets -std=gnu++98. This is used for all the code that ends up in the final JDK. There is a bug that the build tool, adlc, is built without the compiler flags and so uses the default standard. That's what we are trying to resolve upstream in the PR I linked to. Upstream, we test 8u with GCC 9 on Linux. Different vendors use their own GCC versions, some older, some newer. I note the oldest in Gentoo is 10. If you need to support newer GCCs (and clang), I would recommend trying to work with us upstream to do this rather than maintaining a growing pile of patches in the ebuild. The reason I say it's risky is because both the newer -std option and the backports you have are untested upstream. We at Red Hat had to maintain a lot of local patches when OpenJDK first started - hence the IcedTea project - and over the years, we've worked to move closer to upstream, so we can work with largely the same code as everyone else. > We can try -std=gnu++98 if the whole thing builds with it, though. It was > only being used partially when I looked before. See comments above. All the code for the final JDK image should be built with -std=gnu++98. There is a known bug with adlc. If you're seeing something different, I'd be interested to see build logs. I've never tried to build 8u with clang, nor is this tested upstream, so it may be that the logic to add -std=gnu++98 is not fully in effect there. Certainly, the error in the initial comment to this bug is unexpected and there seem to be a number of compiler flags missing.
(In reply to Andrew John Hughes from comment #14) > (In reply to Sam James from comment #13) > > (In reply to Andrew John Hughes from comment #12) > > > > * Build with -std=gnu++14 because of -Wregister for Clang 17+ compat > > > > (bug #918655). > > > > (Part of the build uses -std=gnu++98 but not all of it.) > > > > > > This seems a rather drastic fix for what appears to be > > > https://github.com/openjdk/jdk8u-dev/pull/357 > > > > > > I'm also not aware of anyone building 8u with clang. > > > > > > This seems risky and it would be preferable to help us look into supporting > > > this upstream, rather than piling up local patches in the ebuild. > > > > I'm not sure it's that risky. Both GCC and Clang default to -std=gnu++17 > > right now. > > > > I'm aware of that but I'm not sure how it changes the situation. 8u was > developed against older versions of GCC that defaulted to -std=gnu++98. It > is a stable JDK and we don't tend to backport changes just to silence > compiler warnings, especially if there is a safer alternative. Then it can't really be a risky by itself to pass -std=gnu++14 as I did? Note that the changes I backported are all *essential* to build with GCC 14, which makes various warnings errors by default, and I just happened to shove in -std=gnu++14 to roll back from -std=gnu++17 to fix the -Wregister isuse with Clang. > > When GCC 6 started using a newer default standard, I added the configure > check to OpenJDK 8 which explicitly sets -std=gnu++98. This is used for all > the code that ends up in the final JDK. There is a bug that the build tool, > adlc, is built without the compiler flags and so uses the default standard. > That's what we are trying to resolve upstream in the PR I linked to. > > Upstream, we test 8u with GCC 9 on Linux. Different vendors use their own > GCC versions, some older, some newer. I note the oldest in Gentoo is 10. If > you need to support newer GCCs (and clang), I would recommend trying to work > with us upstream to do this rather than maintaining a growing pile of > patches in the ebuild. > Sure. I have no problem with doing stuff upstream (I already started submitting a bunch of things for e.g. musl-1.2.4 and GCC 14). I'm not really concerned about the patches backported here though. They're all upstream patches, just not backported to 8 yet. Should we request that they be backported? Yes. But they're not bespoke patches I haven't submitted anywhere, or something. (There's links in each of the patches.) > The reason I say it's risky is because both the newer -std option and the > backports you have are untested upstream. We at Red Hat had to maintain a > lot of local patches when OpenJDK first started - hence the IcedTea project > - and over the years, we've worked to move closer to upstream, so we can > work with largely the same code as everyone else. > > > We can try -std=gnu++98 if the whole thing builds with it, though. It was > > only being used partially when I looked before. > > See comments above. All the code for the final JDK image should be built > with -std=gnu++98. There is a known bug with adlc. > Right, so we should backport that and drop -std=gnu++14.
