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

[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
>>> I haven't had the time to look at this yet due to $DAYJOB@SUSE, but I 
>>> should have time tomorrow
>>> as there is a public holiday tomorrow.
>>> 
>>> Also, Magnus should get to a SPARC-T5 running Debian unstable within the 
>>> next hours so he
>>> will be able to perform build tests as well and provide feedback.
>>> 
>>> Sorry for not being able to reply earlier.
>> 
>> Adrian, did you have a chance to look at the zero patch? I’m running out of 
>> things to
>> address and I’m planning on moving forward with the JEP targeting and 
>> integration shortly.
> 
> I haven't tested the changes by Magnus yet, but they look good to me. Magnus
> create a repo on the Linux SPARC porterbox which I can pull from for testing.
> 
> I finally have time to look into it tomorrow morning (CEST) so I can
> officially ACK the changes.

Awesome, let me know how the verification goes and if there are any additional 
changes needed!

Cheers,
Mikael

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

[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 
>> have time tomorrow
>> as there is a public holiday tomorrow.
>>
>> Also, Magnus should get to a SPARC-T5 running Debian unstable within the 
>> next hours so he
>> will be able to perform build tests as well and provide feedback.
>>
>> Sorry for not being able to reply earlier.
> 
> Adrian, did you have a chance to look at the zero patch? I’m running out of 
> things to
> address and I’m planning on moving forward with the JEP targeting and 
> integration shortly.

I haven't tested the changes by Magnus yet, but they look good to me. Magnus
create a repo on the Linux SPARC porterbox which I can pull from for testing.

I finally have time to look into it tomorrow morning (CEST) so I can
officially ACK the changes.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

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

[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/
>>  
>> 
>> incremental: 
>> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/build.incr/open/webrev/
>>  
>> 
>> 
>> I believe I have addressed all the review comments apart from:
>> 
>> * 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 
> have time tomorrow
> as there is a public holiday tomorrow.
> 
> Also, Magnus should get to a SPARC-T5 running Debian unstable within the next 
> hours so he
> will be able to perform build tests as well and provide feedback.
> 
> Sorry for not being able to reply earlier.

Adrian, did you have a chance to look at the zero patch? I’m running out of 
things to address and I’m planning on moving forward with the JEP targeting and 
integration shortly.

Cheers,
Mikael

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

[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 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, e.g. a-z, then "-" is
interpreted as the range separator.  So if you wanted to include a
literal "-" in a []  regex set, you had to put it first or last, since
then it could not be part of a range. The ability to escape - using \ is
much newer, and apparently not supported on AIX.

/Magnus

Thank you to let me know that!

Thanks,
--lx

>
> For your information, the reason I added '-' because I found the suffix 
'-internal' when you build from openjdk source directly.
> "openjdk version "15-internal" 2020-09-15"
>
> thanks,
> --lx
>
>
> On 5/11/20, 9:26 AM, "build-dev on behalf of 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: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 you want.
>
>  /Magnus
>  >
>  > Best regards,
>  >
>  > Martin
>  >
>
>

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

[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 result, a configure
> warning is being produced and crucial flags won't get added for
> compilation. This results in a broken build on such systems.
> 
> Details are in:
> https://bugs.openjdk.java.net/browse/JDK-8244538
> 
> The original JDK 14 patch doesn't apply cleanly post path-
> unshuffeling, because even though JDK-8151841[1] is in 8u,
> JDK-8034788[2] later regressed the
> COMPILER_VERSION_NUMBER sed expression to its prior
> JDK-8151841 form. After this patch, this will be corrected again
> and will include JDK-8233880 changes.
> 
> 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 with -fcommon (crashes on java
>  -version). Passes after.
> 
> Thoughts?
> 
> Thanks,
> Severin
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8151841
> [2] https://bugs.openjdk.java.net/browse/JDK-8034788
> 

That JDK-8034788 seems to have regressed quite a lot :-(

Change looks fine. I was able to do a clean generation of configure, so
I've approved and pushed this.

Thanks,
-- 
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

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

[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, e.g. a-z, then "-" is 
interpreted as the range separator.  So if you wanted to include a 
literal "-" in a []  regex set, you had to put it first or last, since 
then it could not be part of a range. The ability to escape - using \ is 
much newer, and apparently not supported on AIX.


/Magnus



For your information, the reason I added '-' because I found the suffix 
'-internal' when you build from openjdk source directly.
"openjdk version "15-internal" 2020-09-15"

thanks,
--lx


On 5/11/20, 9:26 AM, "build-dev on behalf of 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: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 you want.

 /Magnus
 >
 > Best regards,
 >
 > Martin
 >

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

[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 side-effect, it will finally once again be possible to 
list the dependencies for a rule together with the recipe, fixing a 
shortcoming that has plagues Main.gmk for a long time.


In this patch, I create a trivial version of SetupTarget, and switch 
trivial recipes to use this function. By this, I mean recipes that 
just delegate to another makefile, possible setting a specific target 
and/or make arguments. Specifically, this excludes generated target 
patterns, as for the module phases.


Trivial dependencies are also moved into this function. By this, I 
mean "literal" dependencies. Dependencies that are calculated using 
variables or macros might change if they are moved around in the file, 
and need a more thorough analysis before they can be moved.


My intention is to continue moving targets in Main.gmk into the scope 
of SetupTarget, but to avoid regressions and difficult code reviews, I 
will do this step by step.


Bug: https://bugs.openjdk.java.net/browse/JDK-8244757
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8244757-introduce-SetupTarget/webrev.01


... aand I forgot to add the TARGET argument after I split it out 
from ARGS. MainSupport.gmk is updated:


http://cr.openjdk.java.net/~ihse/JDK-8244757-introduce-SetupTarget/webrev.02/

/Magnus



/Magnus

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

[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 
'-internal' when you build from openjdk source directly. 
"openjdk version "15-internal" 2020-09-15"

thanks,
--lx


On 5/11/20, 9:26 AM, "build-dev on behalf of 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: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 you want.

/Magnus
>
> Best regards,
>
> Martin
>

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

[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 you want.

/Magnus


Best regards,

Martin

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

[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

RFR: JDK-8244757 Introduce SetupTarget in Main.gmk

[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 possible to 
list the dependencies for a rule together with the recipe, fixing a 
shortcoming that has plagues Main.gmk for a long time.


In this patch, I create a trivial version of SetupTarget, and switch 
trivial recipes to use this function. By this, I mean recipes that just 
delegate to another makefile, possible setting a specific target and/or 
make arguments. Specifically, this excludes generated target patterns, 
as for the module phases.


Trivial dependencies are also moved into this function. By this, I mean 
"literal" dependencies. Dependencies that are calculated using variables 
or macros might change if they are moved around in the file, and need a 
more thorough analysis before they can be moved.


My intention is to continue moving targets in Main.gmk into the scope of 
SetupTarget, but to avoid regressions and difficult code reviews, I will 
do this step by step.


Bug: https://bugs.openjdk.java.net/browse/JDK-8244757
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8244757-introduce-SetupTarget/webrev.01


/Magnus

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

[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 into which the 
file was written). Also should resolve the suspicious timestamp code 
noted by Alan, by removing the code altogether, as we can use the 
timestamp provided by the build.

Looks good to me!



The ct.sym will now be reproducible only if the --with-source-date 
option is used. I wonder why at least "current" is not the default - 
that would probably make testing reproducible builds much easier.
That was my original intention, but after working with the patch I grew 
wary. Other tools might pick up SOURCE_DATE_EPOCH and without more 
testing on different platforms I would rather have the default something 
that mimics the old behavior.


/Magnus


How does this look?

Thanks,
    Jan

On 07. 05. 20 17:48, Magnus Ihse Bursie wrote:

On 2020-04-30 14:50, Jan Lahoda wrote:

On 30. 04. 20 14:29, Magnus Ihse Bursie wrote:

On 2020-04-30 12:41, Alan Bateman wrote:



On 30/04/2020 08:03, Jan Lahoda wrote:

Hi,

The building of lib/ct.sym is not reproducible, due to timestamps 
of files inside the file (which is basically a zip file).


The proposed solution is to use a constant timestamp for the 
files inside the ct.sym file. To simplify the construction, the 
CreateSymbols tool does not produce files on the filesystem 
anymore, but rather constructs the ct.sym directly.


Proposed webrev: 
http://cr.openjdk.java.net/~jlahoda/8241616/webrev.00/

JBS: https://bugs.openjdk.java.net/browse/JDK-8241616
1587656816359 = 2020-04-23T15:46:56.359Z. Is there anything 
significant with this timestamp? Magnus might have suggestions but 
maybe it would be saner to pick up the value of DEFAULT_VERSION_DATE.
There is an officially suggested standard, SOURCE_DATE_EPOCH for 
reproducible builds. [1] I have long-term vision to include this in 
the entire JDK build, but has of yet not even started on that. :-(


This might be a good first step to start using it. I can assist in 
making the needed makefile changes to have that environment 
variable available.


I think a standard mechanism would be great. I don't think this 
patch is very urgent, so I am happy to wait some time (rather than 
add a timestamp to symbols and then remove it when there's a 
standard mechanism).


JDK-8244592 is now in mainline, and you can start relying on 
SOURCE_DATE_EPOCH being present in the environment when building.


/Magnus


Thanks,
    Jan



/Magnus

[1] https://reproducible-builds.org/specs/source-date-epoch/


There is some curious code that generates the timestamp with:
   Long.toString(FileTime.from(Instant.now()).toMillis())
Could this use Instant.now().toEpochMilli() instead?

-Alan

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

[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 timestamps are the obvious thing to make reproducible, but there
are other sources of non-determinism, e.g. file system traversal order.

On Thu, Apr 30, 2020 at 12:05 AM Jan Lahoda  wrote:

> Hi,
>
> The building of lib/ct.sym is not reproducible, due to timestamps of
> files inside the file (which is basically a zip file).
>
> The proposed solution is to use a constant timestamp for the files
> inside the ct.sym file. To simplify the construction, the CreateSymbols
> tool does not produce files on the filesystem anymore, but rather
> constructs the ct.sym directly.
>
> Proposed webrev: http://cr.openjdk.java.net/~jlahoda/8241616/webrev.00/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8241616
>
> How does this look?
>
> Thanks,
>  Jan
>

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

[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 should resolve the suspicious timestamp code 
noted by Alan, by removing the code altogether, as we can use the 
timestamp provided by the build.


The ct.sym will now be reproducible only if the --with-source-date 
option is used. I wonder why at least "current" is not the default - 
that would probably make testing reproducible builds much easier.


How does this look?

Thanks,
Jan

On 07. 05. 20 17:48, Magnus Ihse Bursie wrote:

On 2020-04-30 14:50, Jan Lahoda wrote:

On 30. 04. 20 14:29, Magnus Ihse Bursie wrote:

On 2020-04-30 12:41, Alan Bateman wrote:



On 30/04/2020 08:03, Jan Lahoda wrote:

Hi,

The building of lib/ct.sym is not reproducible, due to timestamps 
of files inside the file (which is basically a zip file).


The proposed solution is to use a constant timestamp for the files 
inside the ct.sym file. To simplify the construction, the 
CreateSymbols tool does not produce files on the filesystem 
anymore, but rather constructs the ct.sym directly.


Proposed webrev: 
http://cr.openjdk.java.net/~jlahoda/8241616/webrev.00/

JBS: https://bugs.openjdk.java.net/browse/JDK-8241616
1587656816359 = 2020-04-23T15:46:56.359Z. Is there anything 
significant with this timestamp? Magnus might have suggestions but 
maybe it would be saner to pick up the value of DEFAULT_VERSION_DATE.
There is an officially suggested standard, SOURCE_DATE_EPOCH for 
reproducible builds. [1] I have long-term vision to include this in 
the entire JDK build, but has of yet not even started on that. :-(


This might be a good first step to start using it. I can assist in 
making the needed makefile changes to have that environment variable 
available.


I think a standard mechanism would be great. I don't think this patch 
is very urgent, so I am happy to wait some time (rather than add a 
timestamp to symbols and then remove it when there's a standard 
mechanism).


JDK-8244592 is now in mainline, and you can start relying on 
SOURCE_DATE_EPOCH being present in the environment when building.


/Magnus


Thanks,
    Jan



/Magnus

[1] https://reproducible-builds.org/specs/source-date-epoch/


There is some curious code that generates the timestamp with:
   Long.toString(FileTime.from(Instant.now()).toMillis())
Could this use Instant.now().toEpochMilli() instead?

-Alan

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

[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 that sound
>>> ok?
>> 
>> THe runstatedir changes come and go (even in the jdk8u-dev history),
>> depending on whether Debian's autoconf is used, which patches its
>> autoconf 2.69 build to handle runstatedir.  There hasn't been an
>> autoconf upstream release in many, many years, so going back to older
>> versions will not solve this.  If you want to avoid this change, you
>> either have to use Debian's autoconf, or back it out manually.
>
> I guess it doesn't matter. Having said that, it's a timely reminder
> of how random distro-isms end up in OpenJDK by accident.

The flip side is that distributions carry different patches or use sed
to patch configure scripts.

> And I am *so* *happy* that autoconf is stable upstream. I remember when
> it was changing rapidly, and that was a nightmare.

A new upstream release is in the works:

  

It's true that in the past, you had to have multiple autoconf versions
installed and use the right version depending on the project.  But at
least distributions where providing you with a reasonable choice of
autoconf (and automake) versions.  Today, you can't easily get Debian's
autoconf on Fedora and vice versa, which is clearly not an ideal
situation.

Thanks,
Florian

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

[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?
> 
> THe runstatedir changes come and go (even in the jdk8u-dev history),
> depending on whether Debian's autoconf is used, which patches its
> autoconf 2.69 build to handle runstatedir.  There hasn't been an
> autoconf upstream release in many, many years, so going back to older
> versions will not solve this.  If you want to avoid this change, you
> either have to use Debian's autoconf, or back it out manually.
> 
> Thanks,
> Florian
> 

And this is why checking in generated files should be avoided. I'm glad
it's gone in later OpenJDK versions.
-- 
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

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

[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?
> 
> THe runstatedir changes come and go (even in the jdk8u-dev history),
> depending on whether Debian's autoconf is used, which patches its
> autoconf 2.69 build to handle runstatedir.  There hasn't been an
> autoconf upstream release in many, many years, so going back to older
> versions will not solve this.  If you want to avoid this change, you
> either have to use Debian's autoconf, or back it out manually.

I guess it doesn't matter. Having said that, it's a timely reminder
of how random distro-isms end up in OpenJDK by accident.

And I am *so* *happy* that autoconf is stable upstream. I remember when
it was changing rapidly, and that was a nightmare.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[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. Does that sound
> > ok?
>
> THe runstatedir changes come and go (even in the jdk8u-dev history),
> depending on whether Debian's autoconf is used, which patches its
> autoconf 2.69 build to handle runstatedir.  There hasn't been an
> autoconf upstream release in many, many years, so going back to older
> versions will not solve this.  If you want to avoid this change, you
> either have to use Debian's autoconf, or back it out manually.

OK. Thanks for the heads-up.

Cheers,
Severin

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

[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 jdk8u-dev history),
depending on whether Debian's autoconf is used, which patches its
autoconf 2.69 build to handle runstatedir.  There hasn't been an
autoconf upstream release in many, many years, so going back to older
versions will not solve this.  If you want to avoid this change, you
either have to use Debian's autoconf, or back it out manually.

Thanks,
Florian

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

[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 with -fcommon (crashes on java
> >  -version). Passes after.
> >
> > Thoughts?
>
> That looks fine; I presume the apparently spurious diffs are because
> you used a different version of autoconf to generate generated-configure.sh.

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?

Cheers,
Severin