Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

2020-05-11 Thread Mikael Vidstedt
> On May 11, 2020, at 3:08 PM, John Paul Adrian Glaubitz > wrote: > > Hi Mikael! > > On 5/12/20 12:05 AM, Mikael Vidstedt wrote: * GNM - Magnus to file a follow-up RFE * Zero - Waiting for somebody (Adrian?) to provide more information about what needs to be preserved

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

2020-05-11 Thread John Paul Adrian Glaubitz
Hi Mikael! On 5/12/20 12:05 AM, Mikael Vidstedt wrote: >>> * GNM - Magnus to file a follow-up RFE >>> >>> * Zero - Waiting for somebody (Adrian?) to provide more information about >>> what needs to be preserved >> I haven't had the time to look at this yet due to $DAYJOB@SUSE, but I should >>

Re: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports (build system)

2020-05-11 Thread Mikael Vidstedt
> On May 7, 2020, at 4:18 AM, John Paul Adrian Glaubitz > wrote: > > Hi Mikael! > > On 5/7/20 2:47 AM, Mikael Vidstedt wrote: >> New webrev available here: >> >> webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build/open/webrev/ >> >>

Re: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers

2020-05-11 Thread Severin Gehwolf
Hi Andrew, On Sun, May 10, 2020 at 4:36 PM Andrew Haley wrote: > > On 5/8/20 2:17 PM, Severin Gehwolf wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233880 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233880/01/webrev/ > > > > Testing: Build prior this patch on F32

Re: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers

2020-05-11 Thread Florian Weimer
* Severin Gehwolf: > Thanks for the review! Yes, generated-configure.sh changes are due to > version skew of autoconf being used. I'll try to generate configure on > an older machine so as to avoid this before pushing. Does that sound > ok? THe runstatedir changes come and go (even in the

Re: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers

2020-05-11 Thread Andrew Haley
On 5/11/20 8:58 AM, Florian Weimer wrote: > * Severin Gehwolf: > >> Thanks for the review! Yes, generated-configure.sh changes are due to >> version skew of autoconf being used. I'll try to generate configure on >> an older machine so as to avoid this before pushing. Does that sound >> ok? > >

Re: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers

2020-05-11 Thread Severin Gehwolf
Hi Florian, On Mon, May 11, 2020 at 9:58 AM Florian Weimer wrote: > > * Severin Gehwolf: > > > Thanks for the review! Yes, generated-configure.sh changes are due to > > version skew of autoconf being used. I'll try to generate configure on > > an older machine so as to avoid this before pushing.

Re: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers

2020-05-11 Thread Florian Weimer
* Andrew Haley: > On 5/11/20 8:58 AM, Florian Weimer wrote: >> * Severin Gehwolf: >> >>> Thanks for the review! Yes, generated-configure.sh changes are due to >>> version skew of autoconf being used. I'll try to generate configure on >>> an older machine so as to avoid this before pushing. Does

Re: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers

2020-05-11 Thread Andrew Hughes
On 11/05/2020 08:58, Florian Weimer wrote: > * Severin Gehwolf: > >> Thanks for the review! Yes, generated-configure.sh changes are due to >> version skew of autoconf being used. I'll try to generate configure on >> an older machine so as to avoid this before pushing. Does that sound >> ok? >

RFR: JDK-8244757 Introduce SetupTarget in Main.gmk

2020-05-11 Thread Magnus Ihse Bursie
To be able to support JDK-8244410, we need to have a better way to handle dependencies. For this reason, the macro SetupTarget is introduced. It will take as input everything that is needed to create a top-level target in Main.gmk. As a positive side-effect, it will finally once again be

Re: RFR(XS): 8244756: Build broken with some awk version after JDK-8244248

2020-05-11 Thread Magnus Ihse Bursie
On 2020-05-11 18:17, Doerr, Martin wrote: Hi Magnus, thank you for proposing a fix which allows building with old awk on AIX. Works fine. Here’s the webrev: http://cr.openjdk.java.net/~mdoerr/8244756_AIX_fix_awk_expr/webrev.00/ Would you like to be mentioned as author? Whatever. :) If

Re: RFR(XS): 8244756: Build broken with some awk version after JDK-8244248

2020-05-11 Thread Liu, Xin
Hi, Martin and Magnus, Thank you to fix this problem. sorry, I didn't realize that awk program is less portable. Your script looks good to me. Why it works by reordering \._\- in []. Is it the only potential issue? For your information, the reason I added '-' because I found the suffix

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

2020-05-11 Thread Magnus Ihse Bursie
On 2020-05-11 17:25, Jan Lahoda wrote: Thanks Magnus for the SOURCE_DATE_EPOCH! I've adjusted the patch to use it: http://cr.openjdk.java.net/~jlahoda/8241616/webrev.01/ It also explicitly sets the output of TransitiveDependencies on the command line (before it was passing just the directory

RFR(XS): 8244756: Build broken with some awk version after JDK-8244248

2020-05-11 Thread Doerr, Martin
Hi Magnus, thank you for proposing a fix which allows building with old awk on AIX. Works fine. Here's the webrev: http://cr.openjdk.java.net/~mdoerr/8244756_AIX_fix_awk_expr/webrev.00/ Would you like to be mentioned as author? Best regards, Martin

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

2020-05-11 Thread Martin Buchholz
fyi Build reproducibility has become more important over the years. That is especially true at Google, where reproducible builds are more efficient. We have modified versions of various archivers that can generate deterministic metadata in the archive. And that includes the "jar" command. The file

Re: RFR: JDK-8241616: Timestamps on ct.sym entries lead to non-reproducible builds

2020-05-11 Thread Jan Lahoda
Thanks Magnus for the SOURCE_DATE_EPOCH! I've adjusted the patch to use it: http://cr.openjdk.java.net/~jlahoda/8241616/webrev.01/ It also explicitly sets the output of TransitiveDependencies on the command line (before it was passing just the directory into which the file was written). Also

Re: RFR(XS): 8244756: Build broken with some awk version after JDK-8244248

2020-05-11 Thread Liu, Xin
On 5/11/20, 10:52 AM, "Magnus Ihse Bursie" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 2020-05-11 18:44, Liu, Xin wrote: > Hi, Martin and

Re: [8u] RFR(XS): 8233880: Support compilers with multi-digit major version numbers

2020-05-11 Thread Andrew Hughes
On 08/05/2020 14:17, Severin Gehwolf wrote: > Hi, > > Please review this OpenJDK 8u backport of JDK-8233880. It's a > one-liner change which updates the toolchain.m4 code so as to > recognize multi-digit GCC versions. For example Fedora 32 comes > with GCC 10 and falls afoul this check. As a

Re: RFR: JDK-8244757 Introduce SetupTarget in Main.gmk

2020-05-11 Thread Magnus Ihse Bursie
On 2020-05-11 18:16, Magnus Ihse Bursie wrote: To be able to support JDK-8244410, we need to have a better way to handle dependencies. For this reason, the macro SetupTarget is introduced. It will take as input everything that is needed to create a top-level target in Main.gmk. As a positive

Re: RFR(XS): 8244756: Build broken with some awk version after JDK-8244248

2020-05-11 Thread Magnus Ihse Bursie
On 2020-05-11 18:44, Liu, Xin wrote: Hi, Martin and Magnus, Thank you to fix this problem. sorry, I didn't realize that awk program is less portable. Your script looks good to me. Why it works by reordering \._\- in []. Is it the only potential issue? It's an old trick. If you have a range,