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

[Erik Joelsson]

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\hotspot\variant-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.

On 2018-12-14 05:05, Magnus Ihse Bursie wrote:
> On 2018-12-14 09:58, Andrew Luo wrote:
>> Anyways, got it working with an environment variable, patch is attached.
>>
>> To use:
>>
>> 1. Open WSL
>> 2. Run configure, pass in boot JDK
>> 3. Run make (no extra error messages here).
> This is starting to look really really nice! We're getting WSL 
> support, and some extra improvement for other environments as well! :-)
>
> I'm glad the basic idea seem to work out! Now the usage description is 
> down to exactly what we want! :) I still think we can polish the path 
> mangling a bit more, though. Or possibly, I'm just lost and confused 
> about what's happening right now. :-) I'll try to write down what I 
> think looks a bit odd:
>
> * In spec.gmk.in; why do you change PATH for WSL? I thought we could 
> let PATH stay the way it is, and just set FIXPATH_PATH? (And tell WSL 
> to process FIXPATH_PATH).
>
> * Ideally, I was hoping we could be able to change the $(FIXPATH) 
> expression to be something like:
> FIXPATH=WSLENV:=FIXPATH_PATH FIXPATH_PATH=$(FIXPATH_PATH) 
> $TOPDIR/.../fixpath.exe
>
> That would mean that we could finally get 100% rid of environment 
> variables, and have a fully copy-and-pastable command line, even for 
> Windows tools. (Something we don't have even for cygwin today). In 
> fact, if we can get this to work, I'd like to switch to using such a 
> system (but without the WSLENV) for cygwin/msys as well.
>
> * I also note that you add INCLUDE/LIB to WSLENV in places. The code 
> for this in basics_windows.m4 (line 546) is completele beyond me. What 
> are you trying to achieve here? Also in toolchain.m4; why is not 
> setting PATH to VS_PATH enough? The INCLUDE and LIB variables is 
> not/should not be needed, since we convert these to SYSROOT flags and 
> pass them alongside the compiler. Possibly there is some 
> "bootstrapping" problems in toolchain.m4 which makes us at times run 
> the compiler without SYSROOT flags. Maybe that's what you're running 
> into? But in any case you should not append VS_PATH to PATH, since 
> VS_PATH contains the entire old PATH + what was added by the msdevenv 
> script. (It would be nice if we could filter out just what was added, 
> but that might be tricky.) So replacing PATH with VS_PATH should be 
> just fine, both in the old code and in the WSL case.
>
In configure today, we generate the SYSROOT_CFLAGS but we do not use 
them in the configure script. Instead we rely on INCLUDE/LIB being set. 
This is of course not ideal, but having to set WSLENV=INCLUDE:LIB makes 
it more obvious. It would be better to append SYSROOT_CFLAGS to CFLAGS 
for Cygwin and msys as well, but that change is not required for WSL to 
work.

Replacing the path works for Cygwin, but not for WSL. At least not the 
way we generate the VS_PATH in this patch. The VS_PATH will not inherit 
the PATH from the WSL environment as base, it will get the Windows PATH 
that was set before WSL was launched. We could perhaps improve the 
extraction logic to make this work better. See below.

> * This is a question as much to Erik as to you: is it really correct 
> to *always* rewrite VS_PATH to unix style? (I'm talking about lines 
> 470..486 in toolchain_windows.m4) I think not; this sounds like it 
> will break cygwin. I think we should to this either conditionally on 
> us running on WSL, or we should convert it to a VS_WSL_PATH instead. 
> Or maybe I'm just missing something, I'm starting getting a bit 
> confused about all these paths and conversions...
>
In configure today, we do rewrite it, but it happens implicitly in the 
extraction script. The current version of the patch looks like what I 
posted. I will try to explain. In configure today, we generate 
extract-vs-env.bat, which end up containing lines like this (in cygwin):

C:/cygwin64/bin/bash.exe -c 'echo VS_PATH=\"$PATH\" > set-vs-env.sh

(note the unbalanced '. This is baffling me, but currently works in Cygwin.)

The bat file calls back to bash to evaluate the env variable. When I 
tried to get this to work for WSL, I had trouble getting the quoting to 
work. I had also forgotten about WSLENV so $PATH would not be 
translated, it would hold the default bash path, and for the other 
variables (INCLUDE and LIB) they simply did not get values in bash. My 
solution was to ditch bash here and just generate lines like this instead:

echo VS_PATH="%PATH%" > set-vs-env.sh

This outputs the pure windows versions of the variables. For Cygwin, the 
old construct resulted in an implicitly converted PATH variable (though 
still with spaces!), but LIB and INCLUDE still pure windows. This is why 
we already have the conversion loops for those below. With the new 
construct, all variables remain pure Windows, which is arguably more 
consistent.

So to work around now having pure windows paths in VS_PATH, I added 
another rewrite loop. This is a bit inefficient, but has the benefit of 
generating space safe paths in VS_PATH, which is a must if we are to 
prepend them to FIXPATH.

Maybe we can revert some of this and get back to something closer to the 
current behavior using WSLENV in extract-vs-env.bat, but converting PATH 
between Windows and WSL using WSLENV is tricky as we have seen. The WSL 
unix specific paths (/bin:/usr/bin etc) simply do not translate to 
windows so will get lost when going back and forth. For this reason, I 
do not think we can get around having to append the VS_PATH to PATH 
instead of replacing.

I certainly feel like there are possible improvements to the whole scheme.

> * In toolchain.m4, line 392, looks like the ; should be before $path, 
> not after..? Also, this logic should be in toolchain_windows.m4, and 
> not "pollute" the generic toolchain.m4.
>
I would recommend the macros BASIC_PREPEND_TO_PATH and 
BASIC_APPEND_TO_PATH which I created specifically for this situation.
> * The two fixes filtering out UtilTranslatePathList should not be 
> needed anymore.
>
> * I noted that the windowsShortName.bat file is missing from your 
> patch. Perhaps you forgot a "hg add"?
>
> * In fixpath.c, it looks like you're trying to separate the original 
> path and the fixpath_path with a : (colon), not ; (semicolon). Since 
> this is a Windows path, it should be the latter.
>
> * In Images.gmk, I'd like to see a FIXPATH prefix rather than the 
> EXE_SUFFIX.
> * I'm not entirely certain about the addition of literal ".exe" to all 
> Windows toolchain binaries. It's easier to read than $(EXE_SUFFIX), 
> but the latter makes it abuntantly clear that it's needed. I feel 
> there's a certain risk someone editing those files in the future 
> think, "hey, this .exe is just ugly and is not needed, let's remove 
> it". But then again, I'm not sure about this, and I'd like to hear 
> Erik's opinion on it.
>
I added those in my patch, and did it because we had some tools that 
already defined .exe as suffix. I just figured since we were in a 
microsoft specific block, .exe looked better. We could standardize on 
EXE_SUFFIX. We seem to have a duplication though as EXECUTABLE_SUFFIX is 
also present in some locations.

/Erik

> * I'm curious of the change in filename case in "VC/Auxiliary/Build". 
> Did you encounter any issues regarding filename case, or is it just a 
> matter of aesthetics?
>
> * Did you get around to looking if there's any relevant environment 
> version information to add to the configure log? I googled around a 
> bit, it seems that WSL releases are tied 1-to-1 with Windows releases, 
> so running "ver.exe" might do the trick. (See 
> https://github.com/Microsoft/WSL/issues/2125).
>
> /Magnus
>> Thanks,
>>
>> -Andrew
>>
>> -----Original Message-----
>> From: build-dev <build-dev-bounces at openjdk.java.net> On Behalf Of 
>> Andrew Luo
>> Sent: Thursday, December 13, 2018 11:07 PM
>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Erik Joelsson 
>> <erik.joelsson at oracle.com>
>> Cc: build-dev at openjdk.java.net
>> Subject: RE: [PATCH] Support for building using WSL (Windows 
>> Subsystem for Linux) on Windows
>>
>> Didn't see this message before I sent mine out.  How about an 
>> environment variable instead?  I don't want to make too much changes 
>> to the argument parsing logic, etc. of fixpath, instead in -w mode it 
>> could read an environment variable, perhaps FIXPATH_PATH and set PATH 
>> to that?
>>
>> Thanks,
>>
>> -Andrew
>>
>> -----Original Message-----
>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>> Sent: Thursday, December 13, 2018 10:36 PM
>> To: Erik Joelsson <erik.joelsson at oracle.com>
>> Cc: Andrew Luo <andrewluotechnologies at outlook.com>; 
>> build-dev at openjdk.java.net
>> Subject: Re: [PATCH] Support for building using WSL (Windows 
>> Subsystem for Linux) on Windows
>>
>> Maybe we can get fixpath to help here? It could take an extra 
>> argument with -w, the additional directories to add to PATH before 
>> executing the target command?
>>
>> /Magnus
>>
>>> 13 dec. 2018 kl. 21:36 skrev Erik Joelsson <erik.joelsson at oracle.com>:
>>>
>>>> On 2018-12-13 11:44, Andrew Luo wrote:
>>>> Oh, also, using WSLPATH to set PATH/l causes a LOT of extra output, 
>>>> namely, every time a Win32 executable is run this gets printed:
>>>>
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /usr/local/sbin
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /usr/local/bin
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /usr/sbin
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /usr/bin
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /sbin
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /bin
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /usr/games
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /usr/local/games
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /snap/bin
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /usr/local/sbin
>>>> <3>init: (21845) ERROR: UtilTranslatePathList:2021: Failed to
>>>> translate /usr/local/sbin
>>>>
>>>> Don't know if there's any way to tell WSL to suppress it.
>>> Hm, that becomes tricky. We need to export a PATH to Windows 
>>> processes (Visual Studio processes really) that includes certain VS 
>>> dirs so that they can load the dlls they need. It would be more 
>>> convenient if that windows path could be stored in a different 
>>> environment variable, but it doesn't seem like WSLENV can map 
>>> between different names. Another approach could be to prefix the 
>>> affected commands (CC etc) with something like "WSLENV=PATH/l 
>>> PATH=...", with a filtered down version of the VS_PATH. That would 
>>> also have the added benefit of making the commands we put in 
>>> *.cmdline files be directly executable in a pure shell. Today those 
>>> commands won't work since they rely on an exported PATH, even in 
>>> Cygwin.
>>>
>>> /Erik
>>>
>>>> Thanks,
>>>>
>>>> -Andrew
>>>>
>>>> -----Original Message-----
>>>> From: Andrew Luo
>>>> Sent: Thursday, December 13, 2018 11:43 AM
>>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Magnus Ihse Bursie
>>>> <magnus.ihse.bursie at oracle.com>; build-dev at openjdk.java.net
>>>> Subject: RE: [PATCH] Support for building using WSL (Windows
>>>> Subsystem for Linux) on Windows
>>>>
>>>> Hi Erik,
>>>>
>>>> Thanks for helping out on this.  I made some changes to your patch 
>>>> and can get it working on my system.  It's still building but it 
>>>> seems to be working.  Will update this thread once it's finished 
>>>> building...
>>>>
>>>> Thanks,
>>>>
>>>> -Andrew
>>>>
>>>> -----Original Message-----
>>>> From: Erik Joelsson <erik.joelsson at oracle.com>
>>>> Sent: Thursday, December 13, 2018 10:36 AM
>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew Luo
>>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net
>>>> Subject: Re: [PATCH] Support for building using WSL (Windows
>>>> Subsystem for Linux) on Windows
>>>>
>>>> Hello,
>>>>
>>>> It's nice to see this progressing!
>>>>
>>>> I just wanted to let you know I took your patch from yesterday and 
>>>> started experimenting too. I managed to get configure to 
>>>> automatically find the Visual Studio installation as Magnus 
>>>> described, when running in a pure WSL shell without VS env. I still 
>>>> have some issues with the build though so the patch is not fully 
>>>> working yet. One thing I'm still experimenting with is the method 
>>>> of extraction of the VS variables. I think this can be improved 
>>>> more. In the old implementation we are relying on automatic 
>>>> conversion and sharing of some variables between Windows and the 
>>>> unix emulation (which Cygwin does for PATH and msys magically tries 
>>>> to do for all sorts of stuff). These need explicit declaration 
>>>> using WSLENV in WSL, but that also gives us a lot of control over it.
>>>>
>>>> I have limited time to spend on this, so uploading the patch here 
>>>> for reference. Perhaps there is something there that could inspire 
>>>> you at least. I may get more time to revisit this next week or so.
>>>>
>>>> http://cr.openjdk.java.net/~erikj/windows-wsl/webrev.01/index.html
>>>>
>>>> /Erik
>>>>
>>>>> On 2018-12-13 03:12, Magnus Ihse Bursie wrote:
>>>>>> On 2018-12-13 08:48, Andrew Luo wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I attached the latest patch, which now can use Windows paths.
>>>>> Great!
>>>>>
>>>>> I looked at the code, and it looks really good. Just one request. I
>>>>> understand why you want to unify the similar code between msys and
>>>>> wsl, but unless you have actually verified on an msys system that
>>>>> this does not break anything -- please do not do it. This entire
>>>>> system of getting Windows environments to behave is very brittle,
>>>>> and even things that looks like they "should" work, often turn out
>>>>> not to do so in practice. So even though code duplication is a bad
>>>>> thing in general, in this case I'd rather see that you just added
>>>>> the support for WSL, instead of changing the old code. Unless, of
>>>>> course, you have verified that it does not break msys.
>>>>>
>>>>> I can also add that the code here is really horrendous. I'm sure
>>>>> there's a more efficient way of achieving what we want -- sane,
>>>>> space-free, universally usable paths that can be easily turned into
>>>>> windows paths by fixpath, but there's been too many corner-cases,
>>>>> too much of "oh no, now it breaks on cygwin if the code is in the
>>>>> users home dir!" nasty surprises. Solving this properly would
>>>>> probably involve creating some automated test that can be run on all
>>>>> two (soon
>>>>> three) Windows unix environment. And I've never felt it worth it. So
>>>>> it's been a lot of "well, just add this rewrite here too, just in
>>>>> case, see, now it works!". I'm not proud of it, but it does it's 
>>>>> thing.
>>>>>
>>>>> (I also note that you didn't care about tr:ing the 8.3 path to lower
>>>>> case. It's of course a matter of taste, but since the goal is to
>>>>> transform the path to a unix-style path, I tend to think that a path
>>>>> like /mnt/c/progra~1/micros~1/vc/cl.exe is more easier to the eye
>>>>> than /mnt/c/PROGRA~1/MICROS~1/VC/cl.exe or whatever.)
>>>>>
>>>>>>    The new instructions to build are (assuming 8.3 paths are enabled
>>>>>> on your system...):
>>>>> Right, it's possible to disable 8.3 paths nowadays, yes? We should
>>>>> probably add that to the build documentation.
>>>>>> 1. 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
>>>>>> 2. Start wsl (bash):
>>>>>> wsl
>>>>>> 3.    Run configure:
>>>>>> ./configure
>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_window
>>>>>> s-
>>>>>> x64_bin/jdk-11.0.1 --with-tools-dir="C:\Program Files
>>>>>> (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary"
>>>>>> --with-ucrt-dll-dir="C:\Program Files (x86)\Windows
>>>>>> Kits\10\Redist\ucrt\DLLs\x64"
>>>>>> 4.    Run make
>>>>>> I’ve tested make with the default target as well as “make images”
>>>>> Great, those are much simplified build instructions! If you are
>>>>> happy with them, I can end here. However, I can't refrain from at
>>>>> least mentioning that we do have code in place that should make even
>>>>> a lot of these steps unnecessary. It's up to you if you want to make
>>>>> the additional effort to adapt them to the WSL environment. In order:
>>>>>
>>>>> 1) You should not have to start the Developer command prompt, nor
>>>>> export the INCLUDE and LIBPATH environment variables. We locate the
>>>>> vcenv.bat file (or whatever it's called), run this, and then extract
>>>>> the relevant environment variables. But, maybe that is not possible
>>>>> with that kind of env sharing between bat files and the unix
>>>>> environment in WSL?
>>>>>
>>>>> 2) We should be able to locate the relevant Visual Studio
>>>>> installation and associated helper dll:s automatically, if if is
>>>>> installed in a standard location. If the path rewriting is now
>>>>> working properly, I see no reason why this would not work under 
>>>>> WSL as well.
>>>>>
>>>>> 3) The official stance is that only unix-style paths is allowed as
>>>>> argument to configure flags. Otherwise we can't do things like read
>>>>> the value of the flag and check if the file exists. For certain
>>>>> arguments, this might work anyway, out of pure chance. But it's not
>>>>> recommended. So if it ends up that you really need to point to the
>>>>> visual studio installation, the example in the build confiuration
>>>>> should be something like "--with-tools-dir="/mnt/c/Program Files
>>>>> (x86)/Microsoft Visual Studio/2017/Enterprise/VC/Auxiliary".
>>>>>
>>>>>> The issues regarding the console input redirection I'm still
>>>>>> investigating, but I doubt it's a bug in the build scripts, meaning
>>>>>> it is likely a bug in the (boot) JDK or WSL.  Even if we fix the
>>>>>> JDK, we probably still have to support older boot JDKs (even if the
>>>>>> patch is backported), and waiting for Microsoft to fix a bug in WSL
>>>>>> could take a while (and might only be fixed in a later version of 
>>>>>> Windows).
>>>>>> Thus, I think what we have is a good start, unless you think it's
>>>>>> necessary to root cause the redirection issue first. That said, I
>>>>>> will keep this thread updated with my progress once I figure out
>>>>>> the root cause of the issue.
>>>>> No, it's not necessary to find out the root cause. It would be nice
>>>>> to know, but if the issue is only involving these two tools, and it
>>>>> happens deterministically if it happens, I'm fine. Especially since
>>>>> the workaround was actually an improvement. :-)
>>>>>
>>>>> /Magnus
>>>>>> Thanks,
>>>>>>
>>>>>> -Andrew
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>>>>>> Sent: Wednesday, December 12, 2018 10:54 AM
>>>>>> To: Erik Joelsson <erik.joelsson at oracle.com>; Andrew Luo
>>>>>> <andrewluotechnologies at outlook.com>; build-dev at openjdk.java.net
>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows
>>>>>> Subsystem for Linux) on Windows
>>>>>>
>>>>>>> On 2018-12-12 18:30, Erik Joelsson wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I had the same trouble you describe trying to call cmd to create a
>>>>>>> short path from WSL with an inline script. I managed to it working
>>>>>>> by creating a script file like this:
>>>>>>>
>>>>>>> shortName.cmd:
>>>>>>>
>>>>>>> ---
>>>>>>> @ECHO OFF
>>>>>>> if '%1' NEQ '' echo %~s1
>>>>>>> ---
>>>>>>>
>>>>>>> $ /mnt/c/Windows/System32/cmd.exe /c shortName.cmd "C:\Program 
>>>>>>> Files"
>>>>>>> C:\PROGRA~1
>>>>>>>
>>>>>>> We could put such a script in make/scripts.
>>>>>> That's a clever workaround. Andrew, can you see if you can use that
>>>>>> technique to get the proper space safe path resolution to work? I
>>>>>> think you can copy the msys code straight as it is, and just
>>>>>> replace the call to cmd echo %~sA with cmd /c
>>>>>> $TOPDIR/make/script/shortName.cmd, or whatever you end up calling 
>>>>>> it.
>>>>>>> /Erik
>>>>>>>
>>>>>>>> On 2018-12-11 22:44, Andrew Luo wrote:
>>>>>>>> For the stdin/stdout redirection: basically, the issue was only
>>>>>>>> occurring with those two executables.  Oddly enough, it would
>>>>>>>> occur every time I tried (for SPP the output would be cutoff,
>>>>>>>> presumably because the input was cutoff, and for the other
>>>>>>>> executable,
>>>>>>>> available0 would throw an exception consistently for System.in).
>>>>>>>> I have a hunch this is due to using WINAPI console functions for
>>>>>>>> reading from a WSL shell, but I'm not 100% certain. I plan to
>>>>>>>> try to build a smaller sample that can reproduce the issue, and
>>>>>>>> if it seems to be a Windows bug I will file a bug with Microsoft.
>>>>>> So what you are saying is that the issue was not intermittent, but
>>>>>> always happened for those tools? If so, I can reluctantly agree to
>>>>>> this fix. But I'd appreciate if you could drill down a bit and see
>>>>>> what the problem really is.
>>>>>>
>>>>>> /Magnus
>>>>>>>> As for the short paths, calling cmd.exe from WSL bash seems to be
>>>>>>>> a bit buggy.  cmd.exe, when called from a standard Windows
>>>>>>>> environment, works properly and prints the path, however, when
>>>>>>>> called from WSL, I
>>>>>>>> get:
>>>>>>>>
>>>>>>>> "(C:\Program Files (x86))" was unexpected at this time.
>>>>>>>>
>>>>>>>> I verified that the correct path was being passed to cmd.exe (not
>>>>>>>> a bash escaping issue) by creating my own test executable (C++)
>>>>>>>> that just prints argv[0] ... argv[argc - 1] and when running my
>>>>>>>> text executable from both Windows and WSL I get the same result,
>>>>>>>> however when running cmd.exe with the exact same arguments, it
>>>>>>>> works in Windows but not WSL.  I will file a bug with Microsoft 
>>>>>>>> for this issue.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> -Andrew
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
>>>>>>>> Sent: Tuesday, December 11, 2018 6:18 AM
>>>>>>>> To: Andrew Luo <andrewluotechnologies at outlook.com>; Erik Joelsson
>>>>>>>> <erik.joelsson at oracle.com>; build-dev at openjdk.java.net
>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows
>>>>>>>> Subsystem for Linux) on Windows
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 2018-12-11 14:37, Magnus Ihse Bursie wrote:
>>>>>>>>>> On 2018-12-11 06:25, Andrew Luo wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Yes, I've signed an OCA (I've also contributed changes to other
>>>>>>>>>> groups before, but not build).
>>>>>>>>>>
>>>>>>>>>> Okay, I have fixed the autconf-config* files.
>>>>>>>>>>
>>>>>>>>>> Unfortunately, as Erik mentioned, there is no
>>>>>>>>>> (supported/reliable) way to access the WSL root / from
>>>>>>>>>> /cygdrive/c, or even from Windows (there is a way in reality,
>>>>>>>>>> however, it's not documented/supported by Microsoft and the
>>>>>>>>>> location changes depending on the distribution/store app id/etc.
>>>>>>>>>> so best to avoid using it.) I can see if we can print 
>>>>>>>>>> information about versions however.
>>>>>>>>>>
>>>>>>>>>> Right, WSL requires the .exe extension when accessing an
>>>>>>>>>> executable, as this is Linux behavior (Linux doesn't have
>>>>>>>>>> extensions for executables generally, but that's besides the
>>>>>>>>>> point)...
>>>>>>>>>>
>>>>>>>>>> I fixed BASIC_REMOVE_SYMBOLIC_LINKS - a leftover from another
>>>>>>>>>> approach I tried.
>>>>>>>>>>
>>>>>>>>>> For the redirect, redirect doesn't seem to be working when you
>>>>>>>>>> have a bash shell input piped into a Win32 executable reading
>>>>>>>>>> from stdin using WINAPI.  I'm not sure this is supported by the
>>>>>>>>>> OpenJDK, more likely it might be a Microsoft issue.  For some
>>>>>>>>>> reason, the stdin would be cut off (or I would see an exception
>>>>>>>>>> thrown from
>>>>>>>>>> available0 in FileInputStream).  I personally didn't see any
>>>>>>>>>> harm in changing piping into input/output files (since all the
>>>>>>>>>> inputs/outputs are files anyways!).
>>>>>>>>> Ok, let me be sure I get this right. It is only the redirect of
>>>>>>>>> *input* that fails? (But you fixed both because of consistency).
>>>>>>>>> I agree that the change itself is fine, even better than it is
>>>>>>>>> right now
>>>>>>>>> -- I was mostly worried about the consequences of redirects is
>>>>>>>>> not working; there might be other places that fail. But if
>>>>>>>>> redirecting output works, I think we're mostly fine. That's
>>>>>>>>> something we do all the time, for each executed command, so if
>>>>>>>>> that did not work reliably it would be really bad.
>>>>>>>>>
>>>>>>>>> But still... I tried greping for "<" and there's a lot of
>>>>>>>>> places,
>>>>>>>>> 20+, that redirects input.
>>>>>>>>>
>>>>>>>>> Or did this problem only happen when running *java* as the
>>>>>>>>> recipient of the redirected input?
>>>>>>>>>
>>>>>>>>> This worries me, and while I do think your change makes the
>>>>>>>>> tools have a better UI, I don't like this as a workaround that
>>>>>>>>> will not solve all potential problems. :(
>>>>>>>>>
>>>>>>>>>> I fixed TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE - this was also
>>>>>>>>>> from a few things I had tried earlier.
>>>>>>>>>>
>>>>>>>>>> I disabled the $BASH code because to call bash from Win32 the
>>>>>>>>>> correct way is either "wsl /bin/bash" or just "bash". $BASH
>>>>>>>>>> correctly evaluates to /bin/bash, however
>>>>>>>>>> BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH is implemented in
>>>>>>>>>> terms of wslpath, which can only convert a path under /mnt/c
>>>>>>>>>> back to a Windows path.  Other files under /, for example /bin
>>>>>>>>>> and /bin/bash, cannot be converted to a Windwos path.
>>>>>>>>>>
>>>>>>>>>> The escaping changes I made because it wasn't working. This
>>>>>>>>>> does work with spaces in the path on WSL.  I don't have a
>>>>>>>>>> Cygwin environment to check, perhaps someone else here could 
>>>>>>>>>> help out?
>>>>>>>>>> Otherwise I can refactor that code to use that echo statement
>>>>>>>>>> for WSL and use the old echo statement for Cygwin.
>>>>>>>>> I can check it out the next time I'm on a Windows machine.
>>>>>>>>>
>>>>>>>>>> I have fixed the extraneous debug print statement.
>>>>>>>>>>
>>>>>>>>>> As for Windows vs Linux output - you can still force it to
>>>>>>>>>> build a Linux output binary.  You just need to run configure 
>>>>>>>>>> as follows:
>>>>>>>>>>
>>>>>>>>>> ./configure --with-boot-jdk=/home/andrew/jdk-11.0.1
>>>>>>>>>> ----build=x86_64-unknown-linux-gnu
>>>>>>>>>> --host=x86_64-unknown-linux-gnu
>>>>>>>>>>
>>>>>>>>>> However, there is a behavior change: now, on WSL, by default,
>>>>>>>>>> Windows binaries are targeted.  Previously, Linux binaries were
>>>>>>>>>> the default target.  (Also, you can run configure twice and two
>>>>>>>>>> sets of configurations will be generated, you can actually
>>>>>>>>>> build both images by setting CONF=linux-x86_64-server-release
>>>>>>>>>> or
>>>>>>>>>> CONF=windows-x86_64-server-release)
>>>>>>>>> If you run on WLS, it's reasonable that the default is Windows.
>>>>>>>>> The --build --host combo is good enough for me as a way to force
>>>>>>>>> a linux build; we don't need an extra flag for this somewhat odd
>>>>>>>>> build configuration.
>>>>>>>>>
>>>>>>>>>> As for BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN, wslpath does not
>>>>>>>>>> support
>>>>>>>>>> 8.3 names.  But perhaps the symlink workaround is acceptable
>>>>>>>>>> for now and we can handle the 8.3 naming on WSL in a separate
>>>>>>>>>> change, what do you guys think - personally I think what we
>>>>>>>>>> have (assuming Cygwin still works) is at least a MVP for WSL 
>>>>>>>>>> devs.
>>>>>>>>>> Anyways, at least some people may have to use the symlink
>>>>>>>>>> workaround if they've disabled 8.3 on NTFS.
>>>>>>>>> That's too bad, since it really helped with getting around the
>>>>>>>>> issue with spaces in path that's mandatory on Windows using
>>>>>>>>> default installation of Visual Studio. :(
>>>>>>>>>
>>>>>>>>> Again, sorry if I don't know enough about WSL to know if this is
>>>>>>>>> possible, but on msys we do the following:
>>>>>>>>>        new_path=`cmd /c "for %A in (\"$input_path\") do @echo
>>>>>>>>> %~sA"|$TR \\\\\\\\ / | $TR 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
>>>>>>>>> 'abcdefghijklmnopqrstuvwxyz'`
>>>>>>>>>
>>>>>>>>> That is, we call the Windows cmd.exe using the "%~sA" variable
>>>>>>>>> syntax to print the 8.3 version of the path (input_path is a
>>>>>>>>> "normal" Windows path). Is there any way it's possible to do
>>>>>>>>> this on WSL? It seems reasonable that you should be able to call
>>>>>>>>> cmd.exe and redirect the output.
>>>>>>>>>
>>>>>>>>> I think it will be worth trying to jump through some loops or
>>>>>>>>> doing some dirty tricks to get this to work, because everything
>>>>>>>>> will be
>>>>>>>>> *soooo* much simpler if you can reliably turn paths into
>>>>>>>>> space-safe paths; our normal Windows build depends on it.
>>>>>>>> I also realized that if you make a WSL version of
>>>>>>>> BASIC_FIXUP_EXECUTABLE, then you might be able to add .exe in it.
>>>>>>>> You will still need the EXE_SUFFIX when e.g. looking for the
>>>>>>>> java.exe binary in locating the Boot JDK, but perhaps it will
>>>>>>>> simplify some of the places.
>>>>>>>>
>>>>>>>> I see now that the call to java in Images.gmk really should have
>>>>>>>> been prefixed with $(FIXPATH) instead. Then you would not have
>>>>>>>> needed the EXE_SUFFIX fix there.
>>>>>>>>
>>>>>>>> Also, I suggest you look more closely on how we do things on msys
>>>>>>>> than on cygwin; I have the feeling wsl is closer to msys (in
>>>>>>>> terms of functionality from our perspective) than cygwin.
>>>>>>>>> /Magnus
>>>>>>>>>> Attaching my latest patch (generated using powershell, so to
>>>>>>>>>> properly import you may need to convert UTF16 -> UTF8 and
>>>>>>>>>> change CRLF to just LF, hg tends to be picky)...
>>>>>>>> Looks much better now!
>>>>>>>>
>>>>>>>> Before accepting it, I'd like to understand more about the
>>>>>>>> redirect issue, and see if there really is no way to rewrite the
>>>>>>>> paths in a space-safe manner. Then I think this is good to go.
>>>>>>>>
>>>>>>>> /Magnus
>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> -Andrew
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Erik Joelsson <erik.joelsson at oracle.com>
>>>>>>>>>> Sent: Monday, December 10, 2018 9:19 AM
>>>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>; Andrew
>>>>>>>>>> Luo <andrewluotechnologies at outlook.com>;
>>>>>>>>>> build-dev at openjdk.java.net
>>>>>>>>>> Subject: Re: [PATCH] Support for building using WSL (Windows
>>>>>>>>>> Subsystem for Linux) on Windows
>>>>>>>>>>
>>>>>>>>>> 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/Ho
>>>>>>>>>>>> st
>>>>>>>>>>>> x6
>>>>>>>>>>>> 4/
>>>>>>>>>>>> x64/lib.exe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> export
>>>>>>>>>>>> CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho
>>>>>>>>>>>> st
>>>>>>>>>>>> x6
>>>>>>>>>>>> 4/
>>>>>>>>>>>> x64/cl.exe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> export
>>>>>>>>>>>> CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/H
>>>>>>>>>>>> os
>>>>>>>>>>>> tx
>>>>>>>>>>>> 64
>>>>>>>>>>>> /x64/cl.exe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> export
>>>>>>>>>>>> LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Ho
>>>>>>>>>>>> st
>>>>>>>>>>>> x6
>>>>>>>>>>>> 4/
>>>>>>>>>>>> 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/b
>>>>>>>>>>>> in
>>>>>>>>>>>> /H
>>>>>>>>>>>> os
>>>>>>>>>>>> tx64/x64/dumpbin.exe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 5.       Run configure:
>>>>>>>>>>>>
>>>>>>>>>>>> ./configure
>>>>>>>>>>>> --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_
>>>>>>>>>>>> wi
>>>>>>>>>>>> nd
>>>>>>>>>>>> ow
>>>>>>>>>>>> s-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
>>>>>>>>>>>>
>