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

[Erik Joelsson]

Hello,

On 2018-12-10 02:06, Magnus Ihse Bursie wrote:
>
> On 2018-12-09 20:11, Andrew Luo wrote:
>>
>> 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...

It is indeed possible to build a pure Linux binary in WSL today so I 
think it would be bad to lose that functionality. We certainly need a 
configure flag to control if a Windows or Linux build should be produced 
in this case. This is something I have been thinking about when I 
started tackling WSL builds some time ago but didn't really come up with 
a good solution. I didn't have the time to spend to really see it 
through though, so it's nice to see that someone else is trying.

We could simply use the --with-openjdk-target, that would perhaps be the 
cleanest, but it's also a bit cumbersome. We may need some 
simplification similar to how we have --with-target-bits=32/64 as a 
simple switch (e.g. --with-wsl-target=linux/windows?).

>>
>> 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.
>
I definitely agree with Magnus that to make WSL truly supported, the 
path handling macros need to be replicated. I'm not sure how to solve it 
properly. The root path Magnus is asking for is not defined in WSL. In 
fact, from windows you cannot reach any path in the WSL filesystem. Only 
Windows drives are mounted in WSL, not the other way around. To convert 
to old style paths in Cygwin we rely on the cygpath utility. There is a 
wslpath utility but does it support old style path conversions? If not, 
maybe it's possible to write such a tool in CMD/PowerShell?

/Erik


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