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

[Magnus Ihse Bursie]

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

Can you build without errors if you disable PCH?

Also, a wild guess: can it be related to file permissions? Can you read 
the file properly from both WSL and Windows?

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