[8u] RFR: JDK-8152545 Use preprocessor instead of compiling a program to generate native nio constants
Andrew Haley
aph at redhat.com
Wed Sep 23 08:55:45 UTC 2020
On 22/09/2020 19:32, Simon Tooke wrote:
>
> On 2020-09-22 4:54 a.m., Andrew Haley wrote:
>> On 28/02/2020 18:06, Simon Tooke wrote:
>>> Hello,
>>>
>>> I would like to request approval to backport of JDK-8152545 (Use
>>> preprocessor instead of compiling a program to generate native nio
>>> constants) to jdk8u for buildability reasons. I've personally
>>> encountered toolchains where the current solution doesn't build.
>>>
>>> I had to modify the original webrev to get rid of the SO_REUSEPORT
>>> definition, as it isn't supported in JDK8.
>>>
>>> I've tested this on Windows and macos.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152545
>>>
>>> Original patch: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/e2e318304252
>>>
>>> Modified webrev:
>>> http://cr.openjdk.java.net/~stooke/webrevs/jdk-8152545-jdk8/02/jdk.02
>> Why is this being backported? There's no explanation in the bug report
>> and it doesn't seem to fit any of the usual criteria for a backport.
>>
> The fix removes the need to compile and run a program to get various
> runtime constants which are later compiled into the JDK.
OK.
> This is an impediment to cross-compiles, as the constants (some of which
> are admittedly specified by standards) are those of the host, not target
> platform. So I think it's a good fix for that alone.
Ah, right.
> In addition, I've run into issues in windows and macos builds that this
> will fix (see Aleksey Shipilev's comments). At one time I needed this
> patch to get the 8u macos build going, but I can't confirm that is still
> the case due to other build issues.
Fair enough. Thanks.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the jdk8u-dev
mailing list