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.bur...@oracle.com> 
Sent: Thursday, December 13, 2018 10:36 PM
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

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.joels...@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.joels...@oracle.com>; Magnus Ihse Bursie 
>> <magnus.ihse.bur...@oracle.com>; build-dev@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.joels...@oracle.com>
>> Sent: Thursday, December 13, 2018 10:36 AM
>> To: Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com>; Andrew Luo 
>> <andrewluotechnolog...@outlook.com>; build-dev@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.bur...@oracle.com>
>>>> Sent: Wednesday, December 12, 2018 10:54 AM
>>>> To: Erik Joelsson <erik.joels...@oracle.com>; 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-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.bur...@oracle.com>
>>>>>> Sent: Tuesday, December 11, 2018 6:18 AM
>>>>>> To: Andrew Luo <andrewluotechnolog...@outlook.com>; Erik Joelsson 
>>>>>> <erik.joels...@oracle.com>; build-dev@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.joels...@oracle.com>
>>>>>>>> Sent: Monday, December 10, 2018 9:19 AM
>>>>>>>> To: Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com>; Andrew 
>>>>>>>> Luo <andrewluotechnolog...@outlook.com>;
>>>>>>>> build-dev@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
>>>>>>>>>> 

Reply via email to