Re: RFR: JDK-8220737: Jib based 32 bit windows builds fail
Erik: My recent change for gcc8.2 changed the naming convention for devkits in jib-profiles.js (used for builds at Oracle). This messed up the rare occasions when we configure for a 32bit windows target. This patch fixes that situation specifically for windows 32/64 where we use the same devkit. Bug: https://bugs.openjdk.java.net/browse/JDK-8220737 Webrev: http://cr.openjdk.java.net/~erikj/8220737/webrev.01 Looks good. Tim
RFR: JDK-8220737: Jib based 32 bit windows builds fail
My recent change for gcc8.2 changed the naming convention for devkits in jib-profiles.js (used for builds at Oracle). This messed up the rare occasions when we configure for a 32bit windows target. This patch fixes that situation specifically for windows 32/64 where we use the same devkit. Bug: https://bugs.openjdk.java.net/browse/JDK-8220737 Webrev: http://cr.openjdk.java.net/~erikj/8220737/webrev.01 /Erik
Re: RFR: [8u] 8193764: Cannot set COMPANY_NAME when configuring a build
Looks good to me. On Fri, Mar 15, 2019 at 12:05 PM Andrew John Hughes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193764 > Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8193764/webrev.01/ > > This one applies pretty much as-is, when adjustments are made to use the > jdk-options.m4 file rather than jdk-version.m4, which doesn't exist in > 8u. generated-configure.sh is regenerated rather than patched. > > I've confirmed that a build using --with-vendor-name=$VENDOR sees > $VENDOR appear in the generated spec.gmk. > -- > Andrew :) > > Senior Free Java Software Engineer > 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 > https://keybase.io/gnu_andrew > >
RFR: [8u] 8193764: Cannot set COMPANY_NAME when configuring a build
Bug: https://bugs.openjdk.java.net/browse/JDK-8193764 Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8193764/webrev.01/ This one applies pretty much as-is, when adjustments are made to use the jdk-options.m4 file rather than jdk-version.m4, which doesn't exist in 8u. generated-configure.sh is regenerated rather than patched. I've confirmed that a build using --with-vendor-name=$VENDOR sees $VENDOR appear in the generated spec.gmk. -- Andrew :) Senior Free Java Software Engineer 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 https://keybase.io/gnu_andrew
Re: Fwd: [RFR] [8u] 8217753: Enable HotSpot builds on 5.x Linux kernels
On 14/03/2019 15:31, Erik Joelsson wrote: > Looks good to me. > > /Erik > > On 2019-03-13 17:27, Andrew John Hughes wrote: >> Forwarding to build-dev for wider review. >> >> Forwarded Message >> Subject: [RFR] 8217753: Enable HotSpot builds on 5.x Linux kernels >> Date: Mon, 11 Mar 2019 07:24:48 + >> From: Andrew John Hughes >> To: 'jdk8u-...@openjdk.java.net' >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217753 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8217753/webrev.01/ >> >> This is 8u and below only as it's part of the old HotSpot build replaced >> in 9+. >> >> There's a check in make/linux/Makefile to ensure that a 2.4 or later >> kernel is being used. This has been extended by JDK-7072341 to >> accommodate Linux 3.x and JDK-8074312 for 4.x. 5.x is now imminent [0] >> and the build is broken again [1]. >> >> Given that 2.4 was released over 18 years ago [2], I think now is the >> time to just get rid of this check rather than bumping it yet again. If >> anyone is really trying to build OpenJDK 8 on a 2.2 kernel, I suspect >> they will encounter other issues than a Makefile check, and it seems far >> more likely that, if we just add a '5%' check, someone is going to build >> with Linux 6.x in a few years and hit this same bug again. >> >> [0] https://lwn.net/Articles/776034/ >> [1] https://bugs.gentoo.org/675920 >> [2] http://lkml.iu.edu/hypermail/linux/kernel/0101.0/0776.html Thanks Erik. Pushed: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/hotspot/rev/5af8ec63c21c -- Andrew :) Senior Free Java Software Engineer 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 https://keybase.io/gnu_andrew
Re: Fwd: [RFR] [8u] 8220397: JDK-8036003 backport regresses no_strip builds
On 14/03/2019 15:32, Erik Joelsson wrote: > Looks good. > > /Erik > > On 2019-03-13 17:27, Andrew John Hughes wrote: >> Forwarding to build-dev for wider review. >> >> Forwarded Message >> Subject: [RFR] 8220397: JDK-8036003 backport regresses no_strip builds >> Date: Mon, 11 Mar 2019 07:33:16 + >> From: Andrew John Hughes >> To: 'jdk8u-...@openjdk.java.net' >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8220397 >> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8220397/webrev.01/ >> >> When JDK-8036003 was backported, it added a bunch of conditionals in >> make/common/NativeCompilation.gmk which cause debuginfo to not be >> generated if no_strip is set. However, the cases for ZIP_DEBUGINFO_FILES >> were missed, causing the build to fail, because there's no dependency >> for the .diz target. >> >> I suspect this doesn't show up when the new configure option is >> specified, because ZIP_DEBUGINFO_FILES is toggled appropriately, but it >> does regress my existing builds which don't specify that option. >> >> Simple fix and 8u only. Thanks Erik. Pushed: https://hg.openjdk.java.net/jdk8u/jdk8u-dev/rev/5af73acc6b6c -- Andrew :) Senior Free Java Software Engineer 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 https://keybase.io/gnu_andrew
