For me, /mnt/c was already mounted case insensitive.  Maybe this is only the 
default for the C:\ drive though (or perhaps depends on your Windows/WSL 
version?)

Anyways, I've synced down the sandbox and added a new patch to address some of 
the feedback (and some of my own minor enhancements):

1. Got rid of EXECUTABLE_SUFFIX in favor of EXE_SUFFIX, which had to move 
earlier in the sequence
2. Use $EXE_SUFFIX instead of .exe literal per Magnus' feedback
3. Added information about WSL versioning to build, similar to Cygwin
4. Updated building.md and building.html with WSL build instructions

(By the way, you misspelled my name in your sandbox commit): 
http://hg.openjdk.java.net/jdk/sandbox/rev/12615de8335e

I will work on fixing the Cygwin path extraction in my next patch.  Most likely 
I will just restore the old code for Cygwin while using the new code for WSL, 
unless there are other suggestions... Aside from this, is there any other 
feedback that I should take into account before we can merge this into the main 
repository?

Thanks,

-Andrew

-----Original Message-----
From: Erik Joelsson <erik.joels...@oracle.com> 
Sent: Friday, December 14, 2018 5:42 PM
To: Andrew Luo <andrewluotechnolog...@outlook.com>; Magnus Ihse Bursie 
<magnus.ihse.bur...@oracle.com>
Cc: build-dev@openjdk.java.net
Subject: Re: [PATCH] Support for building using WSL (Windows Subsystem for 
Linux) on Windows

After having configured my WSL to mount using case=off, I was able to 
successfully build images using the latest patch as applied in the sandbox.

/Erik

On 2018-12-14 17:23, Erik Joelsson wrote:
> Hello again,
>
> I took the liberty of creating a bug for this and also a sandbox 
> branch where I've applied your latest patch. If you clone that you can 
> send further patches based on a known state in the sandbox. This will 
> make it easier to see what you are actually doing in each update, as 
> well as give us better references when discussing them. It also gives 
> me the ability to directly change things so we can keep Cygwin/msys 
> working.
>
> https://bugs.openjdk.java.net/browse/JDK-8215445
>
> http://hg.openjdk.java.net/jdk/sandbox/shortlog/12615de8335e
>
> /Erik
>
> On 2018-12-14 16:47, Erik Joelsson wrote:
>> Hello,
>>
>> You beat me to it. I just found the rc.exe problem was that 
>> FIXPATH_PATH in spec.gmk.in was quoted. Make just propagates quotes 
>> verbatim, so then fixpath.c would create a path variable like;
>>
>> $PATH;"$FIXPATH_PATH"
>>
>> Which is why link.exe could not find rc.exe.
>>
>> /Erik
>>
>> On 2018-12-14 16:32, Andrew Luo wrote:
>>> Ok, here's my latest patch (I didn't add your case sensitivity fix 
>>> yet, but will do next patch).  I believe this should get you past 
>>> the rc.exe issues.
>>>
>>> Thanks,
>>>
>>> -Andrew
>>>
>>> -----Original Message-----
>>> From: Erik Joelsson <erik.joels...@oracle.com>
>>> Sent: Friday, December 14, 2018 4:15 PM
>>> To: Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com>
>>> Cc: Andrew Luo <andrewluotechnolog...@outlook.com>;
>>> build-dev@openjdk.java.net
>>> Subject: Re: [PATCH] Support for building using WSL (Windows 
>>> Subsystem for Linux) on Windows
>>>
>>>
>>> On 2018-12-14 16:06, Magnus Ihse Bursie wrote:
>>>>> 14 dec. 2018 kl. 23:42 skrev Erik Joelsson
>>>>> <erik.joels...@oracle.com>:
>>>>>
>>>>> I found the reason it's not failing make. It returns "1" and 
>>>>> NativeCompilation.gmk currently ignores 1 explicitly for Visual 
>>>>> Studio. I added that back in 2014 in 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8065576, but I can't 
>>>>> figure out why. Nothing mentioned in either comment or review.
>>>> Sounds like it's ripe for removal then. :) I wonder what kind of 
>>>> issue you might have run into that caused a returned 1 to happen 
>>>> and yet we didn't want to consider it a failure...
>>> If I'm to guess, I think it's one of the commands we pipe the output 
>>> to when the output is zero. This would explain why it was added 
>>> together with pipefail.
>>>
>>> /Erik
>>>
>>>> /Magnus
>>>>
>>>>> /Erik
>>>>>
>>>>>> On 2018-12-14 13:59, Magnus Ihse Bursie wrote:
>>>>>>
>>>>>>
>>>>>>> On 2018-12-14 22:15, Erik Joelsson wrote:
>>>>>>> I get the same error for pch and it still continues, but this 
>>>>>>> time I let it run until it eventually fails for real when it 
>>>>>>> can't link. Perhaps it's simply cl.exe that isn't returning non 
>>>>>>> zero for this error? When the linker fails, make fails, so 
>>>>>>> propagation doesn't seem broken.
>>>>>> That does also seem really weird, considering that it claims it 
>>>>>> to be a "fatal error". Can you repeat the command at the command 
>>>>>> line and get the failure again, and then check the return value?
>>>>>> Can you rewrite the command line and run it from the devenv 
>>>>>> prompt? That is, is there any indication that the pch file itself 
>>>>>> is messed up, or can it be used if running the compilation that 
>>>>>> should use it from an "ok" prompt?
>>>>>>
>>>>>> /Magnus
>>>>>>> /Erik
>>>>>>>
>>>>>>>> On 2018-12-14 12:55, Andrew Luo wrote:
>>>>>>>> Hmm, I get the rc.exe error as well, but now it is much later 
>>>>>>>> down the line... Still investigating...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Andrew
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Andrew Luo
>>>>>>>> Sent: Friday, December 14, 2018 12:34 PM
>>>>>>>> To: 'Andrew Luo' <andrewluotechnolog...@outlook.com>; Magnus 
>>>>>>>> Ihse Bursie <magnus.ihse.bur...@oracle.com>; Erik Joelsson 
>>>>>>>> <erik.joels...@oracle.com>
>>>>>>>> Cc: build-dev@openjdk.java.net
>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows 
>>>>>>>> Subsystem for Linux) on Windows
>>>>>>>>
>>>>>>>> Try this updated patch with some fixes...
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Andrew
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: build-dev <build-dev-boun...@openjdk.java.net> On Behalf 
>>>>>>>> Of Andrew Luo
>>>>>>>> Sent: Friday, December 14, 2018 12:01 PM
>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com>; Erik 
>>>>>>>> Joelsson <erik.joels...@oracle.com>
>>>>>>>> Cc: build-dev@openjdk.java.net
>>>>>>>> Subject: RE: [PATCH] Support for building using WSL (Windows 
>>>>>>>> Subsystem for Linux) on Windows
>>>>>>>>
>>>>>>>> I think I have a fix for it.  Give me a minute (or a few hours 
>>>>>>>> depending on if it works).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Andrew
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com>
>>>>>>>> Sent: Friday, December 14, 2018 11:42 AM
>>>>>>>> To: Erik Joelsson <erik.joels...@oracle.com>
>>>>>>>> Cc: Andrew Luo <andrewluotechnolog...@outlook.com>;
>>>>>>>> build-dev@openjdk.java.net
>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows 
>>>>>>>> Subsystem for Linux) on Windows
>>>>>>>>
>>>>>>>>
>>>>>>>>> 14 dec. 2018 kl. 20:31 skrev Erik Joelsson
>>>>>>>>> <erik.joels...@oracle.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 2018-12-14 11:05, Magnus Ihse Bursie wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> On 2018-12-14 19:41, Erik Joelsson wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 2018-12-14 10:28, Magnus Ihse Bursie wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On 2018-12-14 19:23, Erik Joelsson wrote:
>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I took your patch for a spin, and configure passes, but I 
>>>>>>>>>>>>> get the same build error I got with my patch:
>>>>>>>>>>>>>
>>>>>>>>>>>>> fatal error C1083: Cannot open compiler intermediate file:
>>>>>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotsp
>>>>>>>>>>>>> ot\
>>>>>>>>>>>>> varia
>>>>>>>>>>>>> nt-server\libjvm\objs\build_libjvm.pch': No such file or 
>>>>>>>>>>>>> directory
>>>>>>>>>>>>>
>>>>>>>>>>>>> This is repeated for every C++ file in Hotspot. I see two 
>>>>>>>>>>>>> issues here. First of all, I need to figure out why the 
>>>>>>>>>>>>> compiler will not find the file, which is clearly there.
>>>>>>>>>>>>> Second, why isn't this failure picked up by make? 
>>>>>>>>>>>>> Somewhere the return value of cl.exe is disappearing.
>>>>>>>>>>>> Can you build without errors if you disable PCH?
>>>>>>>>>> Could you? That is, is it only the PCH that is problematic?
>>>>>>>>> Trying that now.
>>>>>>>>>>>> Also, a wild guess: can it be related to file permissions? 
>>>>>>>>>>>> Can you read the file properly from both WSL and Windows?
>>>>>>>>>>> It is readable, but it could be something with case. The 
>>>>>>>>>>> file is actually called BUILD_LIBJVM.pch, but that is also 
>>>>>>>>>>> how it's given to the compiler command line. Here is the 
>>>>>>>>>>> output from DEBUG_FIXPATH:
>>>>>>>>>> Weird. What if you, after a failed build, rename it to 
>>>>>>>>>> build_libjvm.pch?
>>>>>>>>> Doing that causes a new error:
>>>>>>>>>
>>>>>>>>> d:\erik\jdk-wsl\open\src\hotspot\share\gc\shared\accessBarrierSupport.
>>>>>>>>>  
>>>>>>>>>
>>>>>>>>> cpp : fatal error C1382: the PCH file 
>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v
>>>>>>>>> ari ant-s erver\libjvm\objs\build_libjvm.pch' has been rebuilt 
>>>>>>>>> since 
>>>>>>>>> 'd:\erik\jdk-wsl\build\windows-x86_64-server-release\hotspot\v
>>>>>>>>> ari ant-s erver\libjvm\objs\accessBarrierSupport.obj' was 
>>>>>>>>> generated.
>>>>>>>>> Please rebuild this object
>>>>>>>>>
>>>>>>>>> But I think even more important is that make is not getting 
>>>>>>>>> the error. The build just continues until interrupted.
>>>>>>>> Agree, that's bad.
>>>>>>>>
>>>>>>>> Does fixpath_debug print exit code? If so, what does it say? If 
>>>>>>>> not, we should add that instrumentation.
>>>>>>>>
>>>>>>>> /Magnus
>>>>>>>>
>>>>>>>>>>> Compiling ad_x86_expand.cpp (for jvm.dll) fixpath input line
>>>>>>>>>>>> -wsl\build\windows-x86_64-server-release\configure-support\
>>>>>>>>>>>> bin
>>>>>>>>>>>> \fixp
>>>>>>>>>>> ath.exe -w
>>>>>>>>>> This starts out quite odd..? -wsl\build\...?
>>>>>>>>> I agree, didn't look into that part.
>>>>>>>>>>> /mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.
>>>>>>>>>>> 270
>>>>>>>>>>> /bin/
>>>>>>>>>>> Hostx86/x64/cl.exe
>>>>>>>>>> Also, FWIW, this seems not to have been properly case 
>>>>>>>>>> treated. Which version of the patch are you using?
>>>>>>>>> The last one posted by Andrew: "diff15.txt".
>>>>>>>>>
>>>>>>>>> /Erik
>>>>>>>>>
>>>>>>>>>> /Magnus
>>>>>>>>>>> -showIncludes
>>>>>>>>>>> -Fp/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h
>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/BUILD_LIBJVM.pch
>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS 
>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX 
>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 
>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 
>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows 
>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP 
>>>>>>>>>>> -DTARGET_COMPILER_visCPP
>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 
>>>>>>>>>>> -DCOMPILER2
>>>>>>>>>>> -DINCLUDE_ZGC=0
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho
>>>>>>>>>>> tsp
>>>>>>>>>>> ot/va
>>>>>>>>>>> riant-server/gensrc/adfiles
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/closed/src/hotspot/share
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/cpu/x86
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/ho
>>>>>>>>>>> tsp
>>>>>>>>>>> ot/va
>>>>>>>>>>> riant-server/gensrc
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/precompiled
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/share/include
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/hotspot/os/windows/include
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su
>>>>>>>>>>> ppo
>>>>>>>>>>> rt/mo
>>>>>>>>>>> dules_include/java.base
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/su
>>>>>>>>>>> ppo
>>>>>>>>>>> rt/mo
>>>>>>>>>>> dules_include/java.base/win32 
>>>>>>>>>>> -I/mnt/d/erik/jdk-wsl/open/src/java.base/share/native/libjim
>>>>>>>>>>> age
>>>>>>>>>>> -Z7
>>>>>>>>>>> -d2Zi+ -wd4800 -WX
>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~
>>>>>>>>>>> 1.2
>>>>>>>>>>> 70/at
>>>>>>>>>>> lmfc/include
>>>>>>>>>>> -I/mnt/c/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~
>>>>>>>>>>> 1.2
>>>>>>>>>>> 70/in clude
>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt
>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared
>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um
>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt
>>>>>>>>>>> -I/mnt/c/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt 
>>>>>>>>>>> -O2
>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c
>>>>>>>>>>> -Fo/mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/h
>>>>>>>>>>> ots pot/v ariant-server/libjvm/objs/ad_x86_expand.obj
>>>>>>>>>>> /mnt/d/erik/jdk-wsl/build/windows-x86_64-server-release/hots
>>>>>>>>>>> pot /vari ant-server/gensrc/adfiles/ad_x86_expand.cpp<
>>>>>>>>>>> fixpath using wsl mode, with path list:
>>>>>>>>>>> fixpath converted line
>>>>>>>>>>>> c:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.270
>>>>>>>>>>>> /bi
>>>>>>>>>>>> n/Hos
>>>>>>>>>>> tx86/x64/cl.exe -showIncludes 
>>>>>>>>>>> -Fpd:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp
>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/BUILD_LIBJVM.pch 
>>>>>>>>>>> -Yuprecompiled.hpp -D__STDC_FORMAT_MACROS 
>>>>>>>>>>> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNOMINMAX 
>>>>>>>>>>> -DWIN32_LEAN_AND_MEAN -nologo -MD -MP -D_WINDOWS -DWIN32 
>>>>>>>>>>> -D_JNI_IMPLEMENTATION_ -W3 -DVM_LITTLE_ENDIAN -D_LP64=1 
>>>>>>>>>>> -DPRODUCT -DTARGET_ARCH_x86 -DINCLUDE_SUFFIX_OS=_windows 
>>>>>>>>>>> -DINCLUDE_SUFFIX_CPU=_x86 -DINCLUDE_SUFFIX_COMPILER=_visCPP 
>>>>>>>>>>> -DTARGET_COMPILER_visCPP
>>>>>>>>>>> -DAMD64 "-DHOTSPOT_LIB_ARCH=\"amd64\"" -DCOMPILER1 
>>>>>>>>>>> -DCOMPILER2
>>>>>>>>>>> -DINCLUDE_ZGC=0
>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo
>>>>>>>>>>> t/v arian t-server/gensrc/adfiles 
>>>>>>>>>>> -Id:/erik/jdk-wsl/closed/src/hotspot/share
>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share
>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows
>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/cpu/x86
>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os_cpu/windows_x86
>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspo
>>>>>>>>>>> t/v
>>>>>>>>>>> arian t-server/gensrc
>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/precompiled
>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/share/include
>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/hotspot/os/windows/include
>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor
>>>>>>>>>>> t/m
>>>>>>>>>>> odule
>>>>>>>>>>> s_include/java.base
>>>>>>>>>>> -Id:/erik/jdk-wsl/build/windows-x86_64-server-release/suppor
>>>>>>>>>>> t/m
>>>>>>>>>>> odule
>>>>>>>>>>> s_include/java.base/win32
>>>>>>>>>>> -Id:/erik/jdk-wsl/open/src/java.base/share/native/libjimage 
>>>>>>>>>>> -Z7
>>>>>>>>>>> -d2Zi+ -wd4800 -WX
>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27
>>>>>>>>>>> 0/a
>>>>>>>>>>> tlmfc
>>>>>>>>>>> /include
>>>>>>>>>>> -Ic:/PROGRA~2/MICROS~1/2017/PROFES~1/VC/Tools/MSVC/1416~1.27
>>>>>>>>>>> 0/i nclud e 
>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/ucrt
>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/shared
>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/um
>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/winrt
>>>>>>>>>>> -Ic:/PROGRA~2/WI3CF2~1/10/Include/100177~1.0/cppwinrt -O2 
>>>>>>>>>>> -Oy- "-DTHIS_FILE=\"\"" -c 
>>>>>>>>>>> -Fod:/erik/jdk-wsl/build/windows-x86_64-server-release/hotsp
>>>>>>>>>>> ot/ varia nt-server/libjvm/objs/ad_x86_expand.obj
>>>>>>>>>>> d:/erik/jdk-wsl/build/windows-x86_64-server-release/hotspot/
>>>>>>>>>>> var
>>>>>>>>>>> iant- server/gensrc/adfiles/ad_x86_expand.cpp<
>>>>>>>>>>>
>>>>>>>>>>> An interesting note is that make is rebuilding the pch file 
>>>>>>>>>>> on every invocation so it too has trouble finding the file.
>>>>>>>>>>>
>>>>>>>>>>> /Erik
ÿþdiff -r 12615de8335e doc/building.html

--- a/doc/building.html Fri Dec 14 
17:12:14 2018 -0800

+++ b/doc/building.html Sat Dec 15 
23:10:11 2018 -0800

@@ -145,7 +145,7 @@

 <li><p>Do not check out the source 
code in a path which contains spaces. 
Chances are the build will not work. 
This is most likely to be an issue on 
Windows systems.</p></li>

 <li><p>Do not check out the source 
code in a path which has a very long 
name or is nested many levels deep. 
Chances are you will hit an OS 
limitation during the build.</p></li>

 <li><p>Put the source code on a local 
disk, not a network share. If possible, 
use an SSD. The build process is very 
disk intensive, and having slow disk 
access will significantly increase 
build times. If you need to use a 
network share for the source code, see 
below for suggestions on how to keep 
the build artifacts on a local 
disk.</p></li>

-<li><p>On Windows, extra care must be 
taken to make sure the <a 
href="#cygwin">Cygwin</a> environment 
is consistent. It is recommended that 
you follow this procedure:</p>

+<li><p>On Windows, if using <a 
href="#cygwin">Cygwin</a>, extra care 
must be taken to make sure the 
environment is consistent. It is 
recommended that you follow this 
procedure:</p>

 <ul>

 <li><p>Create the directory that is 
going to contain the top directory of 
the JDK clone by using the 
<code>mkdir</code> command in the 
Cygwin bash shell. That is, do 
<em>not</em> create it using Windows 
Explorer. This will ensure that it will 
have proper Cygwin attributes, and that 
it's children will inherit those 
attributes.</p></li>

 <li><p>Do not put the JDK clone in a 
path under your Cygwin home directory. 
This is especially important if your 
user name contains spaces and/or mixed 
upper and lower case letters.</p></li>

@@ -201,8 +201,11 @@

 <h3 id="windows">Windows</h3>

 <p>Windows XP is not a supported 
platform, but all newer Windows should 
be able to build the JDK.</p>

 <p>On Windows, it is important that 
you pay attention to the instructions 
in the <a 
href="#special-considerations">Special 
Considerations</a>.</p>

-<p>Windows is the only non-POSIX OS 
supported by the JDK, and as such, 
requires some extra care. A POSIX 
support layer is required to build on 
Windows. Currently, the only supported 
such layer is Cygwin. (Msys is no 
longer supported due to a too old bash; 
msys2 and the new Windows Subsystem for 
Linux (WSL) would likely be possible to 
support in a future version but that 
would require effort to implement.)</p>

+<p>Windows is the only non-POSIX OS 
supported by the JDK, and as such, 
requires some extra care. A POSIX 
support layer is required to build on 
Windows. Currently, the only supported 
such layers are Windows Subsystem for 
Linux (WSL) and Cygwin. (Msys is no 
longer supported due to a too old bash; 
msys2 would likely be possible to 
support in a future version but that 
would require effort to implement.)</p>

 <p>Internally in the build system, all 
paths are represented as Unix-style 
paths, e.g. 
<code>/cygdrive/c/hg/jdk9/Makefile</code>
 rather than 
<code>C:\hg\jdk9\Makefile</code>. This 
rule also applies to input to the build 
system, e.g. in arguments to 
<code>configure</code>. So, use 
<code>--with-msvcr-dll=/cygdrive/c/msvcr100.dll</code>
 rather than 
<code>--with-msvcr-dll=c:\msvcr100.dll</code>.
 For details on this conversion, see 
the section on <a 
href="#fixpath">Fixpath</a>.</p>

+<h4 
id="windows-subsystem-for-linux-wsl">Windows
 Subsystem for Linux (WSL)</h4>

+<p>Only Windows 10 1803 or newer is 
supported due to a dependency on the 
wslpath utility and support for 
environment variable sharing through 
WSLENV.</p>

+<p>You may build both Windows and 
Linux binaries from WSL. To build 
Windows binaries, you must use a 
Windows boot JDK (located in a 
Windows-accessible directory). To build 
Linux binaries, you must use a Linux 
boot JDK. The default behavior is to 
build for Windows. To build for Linux, 
pass 
<code>--build=x86_64-unknown-linux-gnu</code>
 and 
<code>--host=x86_64-unknown-linux-gnu</code>
 to <code>configure</code>.</p>

 <h4 id="cygwin">Cygwin</h4>

 <p>A functioning <a 
href="http://www.cygwin.com/">Cygwin</a>
 environment is thus required for 
building the JDK on Windows. If you 
have a 64-bit OS, we strongly recommend 
using the 64-bit version of Cygwin.</p>

 <p><strong>Note:</strong> Cygwin has a 
model of continuously updating all 
packages without any easy way to 
install or revert to a specific version 
of a package. This means that whenever 
you add or update a package in Cygwin, 
you might (inadvertently) update tools 
that are used by the JDK build process, 
and that can cause unexpected build 
problems.</p>

diff -r 12615de8335e doc/building.md

--- a/doc/building.md     Fri Dec 14 
17:12:14 2018 -0800

+++ b/doc/building.md     Sat Dec 15 
23:10:11 2018 -0800

@@ -75,8 +75,8 @@

     network share for the source code, 
see below for suggestions on how to 
keep

     the build artifacts on a local 
disk.

 

-  * On Windows, extra care must be 
taken to make sure the 
[Cygwin](#cygwin)

-    environment is consistent. It is 
recommended that you follow this

+  * On Windows, if using 
[Cygwin](#cygwin), extra care must be 
taken to make sure

+    the environment is consistent. It 
is recommended that you follow this

     procedure:

 

       * Create the directory that is 
going to contain the top directory of 
the

@@ -174,10 +174,10 @@

 

 Windows is the only non-POSIX OS 
supported by the JDK, and as such, 
requires

 some extra care. A POSIX support layer 
is required to build on Windows.

-Currently, the only supported such 
layer is Cygwin. (Msys is no longer

-supported due to a too old bash; msys2 
and the new Windows Subsystem for Linux

-(WSL) would likely be possible to 
support in a future version but that 
would

-require effort to implement.)

+Currently, the only supported such 
layers are Windows Subsystem for Linux 
(WSL)

+and Cygwin. (Msys is no longer 
supported due to a too old bash; msys2 
would 

+likely be possible to support in a 
future version but that would require 
effort

+to implement.)

 

 Internally in the build system, all 
paths are represented as Unix-style 
paths,

 e.g. `/cygdrive/c/hg/jdk9/Makefile` 
rather than `C:\hg\jdk9\Makefile`. This

@@ -186,6 +186,17 @@

 `--with-msvcr-dll=c:\msvcr100.dll`. 
For details on this conversion, see the 
section

 on [Fixpath](#fixpath).

 

+#### Windows Subsystem for Linux (WSL)

+

+Only Windows 10 1803 or newer is 
supported due to a dependency on the 
wslpath utility

+and support for environment variable 
sharing through WSLENV.

+

+You may build both Windows and Linux 
binaries from WSL. To build Windows 
binaries,

+you must use a Windows boot JDK 
(located in a Windows-accessible 
directory). To build 

+Linux binaries, you must use a Linux 
boot JDK. The default behavior is to 
build for

+Windows. To build for Linux, pass 
`--build=x86_64-unknown-linux-gnu` and 

+`--host=x86_64-unknown-linux-gnu` to 
`configure`.

+

 #### Cygwin

 

 A functioning 
[Cygwin](http://www.cygwin.com/) 
environment is thus required for

diff -r 12615de8335e 
make/autoconf/basics.m4

--- a/make/autoconf/basics.m4     Fri Dec 
14 17:12:14 2018 -0800

+++ b/make/autoconf/basics.m4     Sat Dec 
15 23:10:11 2018 -0800

@@ -616,6 +616,7 @@

   BASIC_PATH_PROGS(CPIO, [cpio 
bsdcpio])

   BASIC_PATH_PROGS(NICE, nice)

   BASIC_PATH_PROGS(PANDOC, pandoc)

+  BASIC_PATH_PROGS(LSB_RELEASE, 
lsb_release)

 

   BASIC_PATH_PROGS(CMD, [cmd.exe 
/mnt/c/Windows/System32/cmd.exe])

 ])

@@ -638,13 +639,14 @@

 

   if test "x$OPENJDK_TARGET_OS" = 
"xwindows"; then

     PATH_SEP=";"

+    EXE_SUFFIX=".exe"

     BASIC_CHECK_PATHS_WINDOWS

   else

     PATH_SEP=":"

-    EXECUTABLE_SUFFIX=""

+    EXE_SUFFIX=""

   fi

   AC_SUBST(PATH_SEP)

-  AC_SUBST(EXECUTABLE_SUFFIX)

+  AC_SUBST(EXE_SUFFIX)

 

   # We get the top-level directory 
from the supporting wrappers.

   AC_MSG_CHECKING([for top-level 
directory])

diff -r 12615de8335e 
make/autoconf/basics_windows.m4

--- a/make/autoconf/basics_windows.m4     
Fri Dec 14 17:12:14 2018 -0800

+++ b/make/autoconf/basics_windows.m4     
Sat Dec 15 23:10:11 2018 -0800

@@ -464,7 +464,6 @@

     if test "x$test_cygdrive_prefix" = 
x; then

       AC_MSG_ERROR([Your cygdrive 
prefix is not /cygdrive. This is 
currently not supported. Change with 
mount -c.])

     fi

-    EXECUTABLE_SUFFIX=""

   elif test "x$OPENJDK_BUILD_OS_ENV" = 
"xwindows.msys"; then

     AC_MSG_CHECKING([msys release])

     MSYS_VERSION=`$UNAME -r`

@@ -479,9 +478,26 @@

     
BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(MSYS_ROOT_PATH)

     AC_MSG_RESULT([$MSYS_ROOT_PATH])

     
WINDOWS_ENV_ROOT_PATH="$MSYS_ROOT_PATH"

-    EXECUTABLE_SUFFIX=""

   elif test "x$OPENJDK_BUILD_OS_ENV" = 
"xwindows.wsl"; then

-    EXECUTABLE_SUFFIX=".exe"

+    AC_MSG_CHECKING([Windows version])

+    # m4 replaces [ and ] so we use 
@<:@ and @:>@ instead

+    WINDOWS_VERSION=`$CMD /c ver.exe | 
$EGREP -o 
'(@<:@0-9@:>@+\.)+@<:@0-9@:>@+'`

+    AC_MSG_RESULT([$WINDOWS_VERSION])

+

+    AC_MSG_CHECKING([WSL kernel 
version])

+    WSL_KERNEL_VERSION=`$UNAME -v`

+    
AC_MSG_RESULT([$WSL_KERNEL_VERSION])

+

+    AC_MSG_CHECKING([WSL kernel 
release])

+    WSL_KERNEL_RELEASE=`$UNAME -r`

+    
AC_MSG_RESULT([$WSL_KERNEL_RELEASE])

+     

+    AC_MSG_CHECKING([WSL 
distribution])

+    WSL_DISTRIBUTION=`$LSB_RELEASE -d 
| sed 's/Description:\t//'`

+    AC_MSG_RESULT([$WSL_DISTRIBUTION])

+

+    WINDOWS_ENV_VENDOR='WSL'

+    
WINDOWS_ENV_VERSION="$WSL_DISTRIBUTION 
$WSL_KERNEL_VERSION $WSL_KERNEL_RELEASE 
(on Windows build $WINDOWS_VERSION)"

   else

     AC_MSG_ERROR([Unknown Windows 
environment. Neither cygwin, msys, nor 
wsl was detected.])

   fi

diff -r 12615de8335e 
make/autoconf/boot-jdk.m4

--- a/make/autoconf/boot-jdk.m4 Fri Dec 
14 17:12:14 2018 -0800

+++ b/make/autoconf/boot-jdk.m4 Sat Dec 
15 23:10:11 2018 -0800

@@ -63,18 +63,18 @@

     # If previous step claimed to have 
found a JDK, check it to see if it 
seems to be valid.

     if test "x$BOOT_JDK_FOUND" = 
xmaybe; then

       # Do we have a bin/java?

-      if test ! -x 
"$BOOT_JDK/bin/java$EXECUTABLE_SUFFIX"; 
then

+      if test ! -x 
"$BOOT_JDK/bin/java$EXE_SUFFIX"; then

         AC_MSG_NOTICE([Potential Boot 
JDK found at $BOOT_JDK did not contain 
bin/java; ignoring])

         BOOT_JDK_FOUND=no

       else

         # Do we have a bin/javac?

-        if test ! -x 
"$BOOT_JDK/bin/javac$EXECUTABLE_SUFFIX";
 then

+        if test ! -x 
"$BOOT_JDK/bin/javac$EXE_SUFFIX"; then

           AC_MSG_NOTICE([Potential 
Boot JDK found at $BOOT_JDK did not 
contain bin/javac; ignoring])

           AC_MSG_NOTICE([(This might 
be an JRE instead of an JDK)])

           BOOT_JDK_FOUND=no

         else

           # Oh, this is looking good! 
We probably have found a proper JDK. Is 
it the correct version?

-          
BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java$EXECUTABLE_SUFFIX"
 $USER_BOOT_JDK_OPTIONS -version 2>&1 | 
$HEAD -n 1`

+          
BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java$EXE_SUFFIX"
 $USER_BOOT_JDK_OPTIONS -version 2>&1 | 
$HEAD -n 1`

           if [ [[ "$BOOT_JDK_VERSION" 
=~ "Picked up" ]] ]; then

             AC_MSG_NOTICE([You have 
_JAVA_OPTIONS or JAVA_TOOL_OPTIONS set. 
This can mess up the build. Please use 
--with-boot-jdk-jvmargs instead.])

             AC_MSG_NOTICE([Java 
reports: "$BOOT_JDK_VERSION".])

@@ -101,7 +101,7 @@

             AC_MSG_CHECKING([for Boot 
JDK])

             AC_MSG_RESULT([$BOOT_JDK])

             AC_MSG_CHECKING([Boot JDK 
version])

-            
BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java$EXECUTABLE_SUFFIX"
 $USER_BOOT_JDK_OPTIONS -version 2>&1 | 
$TR '\n\r' '  '`

+            
BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java$EXE_SUFFIX"
 $USER_BOOT_JDK_OPTIONS -version 2>&1 | 
$TR '\n\r' '  '`

             
AC_MSG_RESULT([$BOOT_JDK_VERSION])

           fi # end check jdk version

         fi # end check javac

@@ -335,11 +335,11 @@

   AC_SUBST(BOOT_JDK)

 

   # Setup tools from the Boot JDK.

-  BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVA, 
java$EXECUTABLE_SUFFIX)

-  BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVAC, 
javac$EXECUTABLE_SUFFIX)

-  
BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVADOC, 
javadoc$EXECUTABLE_SUFFIX)

-  BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAR, 
jar$EXECUTABLE_SUFFIX)

-  
BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JARSIGNER,
 jarsigner$EXECUTABLE_SUFFIX)

+  BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVA, 
java$EXE_SUFFIX)

+  BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVAC, 
javac$EXE_SUFFIX)

+  
BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAVADOC, 
javadoc$EXE_SUFFIX)

+  BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JAR, 
jar$EXE_SUFFIX)

+  
BOOTJDK_CHECK_TOOL_IN_BOOTJDK(JARSIGNER,
 jarsigner$EXE_SUFFIX)

 

   # Finally, set some other options...

 

diff -r 12615de8335e 
make/autoconf/spec.gmk.in

--- a/make/autoconf/spec.gmk.in Fri Dec 
14 17:12:14 2018 -0800

+++ b/make/autoconf/spec.gmk.in Sat Dec 
15 23:10:11 2018 -0800

@@ -123,8 +123,7 @@

   # On Windows, the Visual Studio 
toolchain needs the PATH to be adjusted

   # to include Visual Studio tools 
(this needs to be in cygwin/msys 
style).

   ifeq ($(OPENJDK_TARGET_OS_ENV), 
windows.wsl)

-    export 
FIXPATH_PATH:=@VS_PATH_WINDOWS@

-    export 
WSLENV:=$(WSLENV):FIXPATH_PATH:DEBUG_FIXPATH

+    export FIXPATH_WSL:=@FIXPATH_WSL@

   else

     export PATH:=@VS_PATH@

   endif

diff -r 12615de8335e 
make/autoconf/toolchain.m4

--- a/make/autoconf/toolchain.m4       Fri 
Dec 14 17:12:14 2018 -0800

+++ b/make/autoconf/toolchain.m4       Sat 
Dec 15 23:10:11 2018 -0800

@@ -180,7 +180,6 @@

     SHARED_LIBRARY='[$]1.dll'

     STATIC_LIBRARY='[$]1.lib'

     OBJ_SUFFIX='.obj'

-    EXE_SUFFIX='.exe'

   else

     LIBRARY_PREFIX=lib

     SHARED_LIBRARY_SUFFIX='.so'

@@ -188,7 +187,6 @@

     SHARED_LIBRARY='lib[$]1.so'

     STATIC_LIBRARY='lib[$]1.a'

     OBJ_SUFFIX='.o'

-    EXE_SUFFIX=''

     if test "x$OPENJDK_TARGET_OS" = 
xmacosx; then

       # For full static builds, we're 
overloading the SHARED_LIBRARY

       # variables in order to limit 
the amount of changes required.

@@ -212,7 +210,6 @@

   AC_SUBST(SHARED_LIBRARY)

   AC_SUBST(STATIC_LIBRARY)

   AC_SUBST(OBJ_SUFFIX)

-  AC_SUBST(EXE_SUFFIX)

 ])

 

 # Determine which toolchain type to 
use, and make sure it is valid for this

@@ -281,13 +278,13 @@

 

   TOOLCHAIN_CC_BINARY_clang="clang"

   TOOLCHAIN_CC_BINARY_gcc="gcc"

-  
TOOLCHAIN_CC_BINARY_microsoft="cl$EXECUTABLE_SUFFIX"

+  
TOOLCHAIN_CC_BINARY_microsoft="cl$EXE_SUFFIX"

   TOOLCHAIN_CC_BINARY_solstudio="cc"

   TOOLCHAIN_CC_BINARY_xlc="xlc_r"

 

   TOOLCHAIN_CXX_BINARY_clang="clang++"

   TOOLCHAIN_CXX_BINARY_gcc="g++"

-  
TOOLCHAIN_CXX_BINARY_microsoft="cl$EXECUTABLE_SUFFIX"

+  
TOOLCHAIN_CXX_BINARY_microsoft="cl$EXE_SUFFIX"

   TOOLCHAIN_CXX_BINARY_solstudio="CC"

   TOOLCHAIN_CXX_BINARY_xlc="xlC_r"

 

@@ -706,7 +703,7 @@

     # In the Microsoft toolchain we 
have a separate LD command "link".

     # Make sure we reject 
/usr/bin/link (as determined in 
CYGWIN_LINK), which is

     # a cygwin program for something 
completely different.

-    AC_CHECK_PROG([LD], 
[link.exe],[link.exe],,, 
[$CYGWIN_LINK])

+    AC_CHECK_PROG([LD], 
[link$EXE_SUFFIX],[link$EXE_SUFFIX],,, 
[$CYGWIN_LINK])

     BASIC_FIXUP_EXECUTABLE(LD)

     # Verify that we indeed succeeded 
with this trick.

     AC_MSG_CHECKING([if the found 
link.exe is actually the Visual Studio 
linker])

@@ -758,7 +755,7 @@

   #

   if test "x$TOOLCHAIN_TYPE" = 
xmicrosoft; then

     # The corresponding ar tool is 
lib.exe (used to create static 
libraries)

-    AC_CHECK_PROG([AR], 
[lib.exe],[lib.exe],,,)

+    AC_CHECK_PROG([AR], 
[lib$EXE_SUFFIX],[lib$EXE_SUFFIX],,,)

   elif test "x$TOOLCHAIN_TYPE" = xgcc; 
then

     BASIC_CHECK_TOOLS(AR, ar gcc-ar)

   else

@@ -782,12 +779,12 @@

   fi

 

   if test "x$TOOLCHAIN_TYPE" = 
xmicrosoft; then

-    AC_CHECK_PROG([MT], [mt.exe], 
[mt.exe],,, [/usr/bin/mt])

+    AC_CHECK_PROG([MT], 
[mt$EXE_SUFFIX], [mt$EXE_SUFFIX],,, 
[/usr/bin/mt])

     BASIC_FIXUP_EXECUTABLE(MT)

     # Setup the resource compiler (RC)

-    AC_CHECK_PROG([RC], [rc.exe], 
[rc.exe],,, [/usr/bin/rc])

+    AC_CHECK_PROG([RC], 
[rc$EXE_SUFFIX], [rc$EXE_SUFFIX],,, 
[/usr/bin/rc])

     BASIC_FIXUP_EXECUTABLE(RC)

-    AC_CHECK_PROG([DUMPBIN], 
[dumpbin.exe], [dumpbin.exe],,,)

+    AC_CHECK_PROG([DUMPBIN], 
[dumpbin$EXE_SUFFIX], 
[dumpbin$EXE_SUFFIX],,,)

     BASIC_FIXUP_EXECUTABLE(DUMPBIN)

     # We need to check for 
'msbuild.exe' because at the place 
where we expect to

     # find 'msbuild.exe' there's also 
a directory called 'msbuild' and 
configure

@@ -796,7 +793,7 @@

     # Notice that we intentionally 
don't fix up the path to MSBUILD 
because we

     # will call it in a DOS shell 
during freetype detection on Windows 
(see

     # 'LIB_SETUP_FREETYPE' in 
"libraries.m4"

-    AC_CHECK_PROG([MSBUILD], 
[msbuild.exe], [msbuild.exe],,,)

+    AC_CHECK_PROG([MSBUILD], 
[msbuild$EXE_SUFFIX], 
[msbuild$EXE_SUFFIX],,,)

   fi

 

   if test "x$OPENJDK_TARGET_OS" = 
xsolaris; then

Reply via email to