[PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows

Mon Dec 10 10:06:47 UTC 2018

Hi Andrew,

Interesting! We've been thinking about adding support for WSL for some 
time now, but never gotten around to it. It's really appreciated to get 
your help here. Just a check, have you signed the OCA?

Overall, I think your patch looks clean and well written! I still have 
some comments/questions, though:

* Due to license issues, we cannot change the autoconf-config.* files. 
That's why we have the two wrapper files, that adjust the input/output 
to the corresponding original autoconf file.

* For cygwin/msys we do this extra detection step in basics_windows.m4 
where we try to locate and describe the "unix" root directory in terms 
of a fully qualified unix path, that is, something like 
/cygdrive/c/cygwin64. I'm not sure if it's actively used anymore, but 
it's printed in the configure log, and I've found it very helpful when 
analyzing problems given a log. I don't know the details of how WSL 
work, but if it's similar (e.g. the root of the linux file system can be 
expressed as a path using mounts), I'd appreciate if it could be 
printed, too. Also, the cygwin/msys version is printed; I'm not sure 
about the possibilities here, but perhaps the relevant information is 
the Windows version, lsb_base -a for the virtual linux, and possibly a 
WSL version number, if there is such a thing..?

* It's a bit sad that you have to specify the .exe all over the place. 
:( But not much to do about it, I guess. I'm suspecting that there are 
still places you have missed to add the $EXECUTABLE_SUFFIX, but they 
will probably turn up quickly once this starts getting used for real.

* Was BASIC_REMOVE_SYMBOLIC_LINKS not working properly? Maybe it's 
better to try and fix it, than work around it...

* What's the deal with changing the redirect for 
TOOL_GENERATECURRENCYDATA and TOOL_SPP? Did redirects not work? That 
worries me a bit, since we have lots of other places with redirects.

* I'm not sure why you put part of the code in 
TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE into an else clause. The idea is 
that TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT will do nothing if 
we've already located VS, so to avoid a long chain of if ... elsif we 
just call it repeatedly, and relies on the fact that it does not do 
anything if VS has been found. Is the subsequent 
TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT calls failing somehow?

* The following code was disabled by you for wsl:

         WINPATH_BASH="$BASH"
BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH([WINPATH_BASH])

Was it reading $BASH that was problematic, or the call to 
BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH?

* The changes in escaping quotes in the env detection script, like:
       $ECHO "$WINPATH_BASH"' -c "echo VS_PATH=\\\"\"$PATH\"\\\" > 
set-vs-env.sh"' \
makes me a bit nervous. Have you verified that this does not break on 
cygwin, or with spaces in the path? I can no longer state exactly why it 
looks the way it does, but I know that it's the effort of a lot of trial 
and error on different platforms (cygwin and msys) and different 
situations. Since we have no good way of running automatic tests for all 
different platforms, changes such as these makes me nervous. That's not 
saying that it's bad, but I'd like to see some extra testing.

* This looks like some left-over debug output:

       AC_MSG_NOTICE($VS_ENV_TMP_DIR)

And finally some replies to your mail:

On 2018-12-09 20:11, Andrew Luo wrote:
> Hi Everyone,
>
> I've been working on getting the OpenJDK to build on WSL (Windows Subsystem for Linux).  Currently, our Windows build uses Cygwin.  Given that WSL is provided with newer versions of the OS (and doesn't suffer from many of the issues that Cygwin does, given that it is built into the Windows kernel), I think it would be great if OpenJDK would support building on WSL.  I've attached a patch with my proposed changes.
>
> One important thing to note is that the WSL build targets Windows.  It is also possible to use WSL to target itself (a WSL Linux binary) or even other distributions of Linux.  I have not implemented that yet, but I think I could do that as a next step if you guys think it would be useful (at least I think it would be useful, then you can test your changes for both Windows and Linux on one system...).
I think if you just run configure ordinarily, it will behave like a 
Linux system and build the Linux image right out-of-the-box..? But then 
again, maybe that behavior is negated by your changes to config.guess 
and platform.m4. So maybe we need a flag to configure to control this...
>
> Steps in case you want to try this out:
>
>
> 1.       Due to autotools not handling spaces well, you have to create symlinks in Windows that will allow you to access Windows Kits and the VC++ compiler without spaces in the path:
>
> mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio"
>
> mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits"
That's a bit odd. We encounter spaces in paths on Windows normally on 
cygwin and msys, and that works fine. I suspect there is something 
missing with the rewriting functions. What we do, is that we rewrite 
paths with spaces to paths without spaces, by using the old 8+3 
compatibility names, so we get something like 
"/cygdrive/c/progra~1/microso~2" from "C:\Program Files (x86)\Microsoft 
Visual Studio". Have a look at BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I 
think you need a WSL version of that, as well as of 
BASIC_FIXUP_PATH_CYGWIN. (And you need to call the BASIC_FIXUP_PATH_WSL 
from BASIC_FIXUP_PATH.)

If you get these parts right, I don't think you will need any of the 
special instructions below to build. In fact, as long as C:\... is 
properly remapped, the normal VS autodetect code should work just fine. 
And perhaps you can even revert some of the scarier changes in 
toolchain_windows.m4.

/Magnus
>
> 2.       wsl must be started from a Windows Developer command prompt.  To ensure the correct environment variables are propagated from Windows to WSL, you can run the following commands:
>
> set WSLENV=INCLUDE/l:LIBPATH/l
>
> 3.       Start wsl (bash):
>
> wsl
>
> 4.       After starting bash you must set your compiler variables to explicitly point to the correct tools:
>
> export AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/lib.exe
>
> export CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe
>
> export CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe
>
> export LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/link.exe
>
> export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe
>
> export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe
>
> export DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/dumpbin.exe
>
> 5.       Run configure:
>
> ./configure --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1 --with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary" --with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64"
>
> 6.       Run make
>
> I've tested make with the default target as well as "make images"
>
> Let me know if you have any feedback/comments.
>
> Thanks,
>
> -Andrew
>