[PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows (original) (raw)
Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Mon Dec 10 10:06:47 UTC 2018
- Previous message (by thread): [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows
- Next message (by thread): [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Andrew,
Interesting! We've been thinking about adding support for WSL for some time now, but never gotten around to it. It's really appreciated to get your help here. Just a check, have you signed the OCA?
Overall, I think your patch looks clean and well written! I still have some comments/questions, though:
Due to license issues, we cannot change the autoconf-config.* files. That's why we have the two wrapper files, that adjust the input/output to the corresponding original autoconf file.
For cygwin/msys we do this extra detection step in basics_windows.m4 where we try to locate and describe the "unix" root directory in terms of a fully qualified unix path, that is, something like /cygdrive/c/cygwin64. I'm not sure if it's actively used anymore, but it's printed in the configure log, and I've found it very helpful when analyzing problems given a log. I don't know the details of how WSL work, but if it's similar (e.g. the root of the linux file system can be expressed as a path using mounts), I'd appreciate if it could be printed, too. Also, the cygwin/msys version is printed; I'm not sure about the possibilities here, but perhaps the relevant information is the Windows version, lsb_base -a for the virtual linux, and possibly a WSL version number, if there is such a thing..?
It's a bit sad that you have to specify the .exe all over the place. :( But not much to do about it, I guess. I'm suspecting that there are still places you have missed to add the $EXECUTABLE_SUFFIX, but they will probably turn up quickly once this starts getting used for real.
Was BASIC_REMOVE_SYMBOLIC_LINKS not working properly? Maybe it's better to try and fix it, than work around it...
What's the deal with changing the redirect for TOOL_GENERATECURRENCYDATA and TOOL_SPP? Did redirects not work? That worries me a bit, since we have lots of other places with redirects.
I'm not sure why you put part of the code in TOOLCHAIN_FIND_VISUAL_STUDIO_BAT_FILE into an else clause. The idea is that TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT will do nothing if we've already located VS, so to avoid a long chain of if ... elsif we just call it repeatedly, and relies on the fact that it does not do anything if VS has been found. Is the subsequent TOOLCHAIN_CHECK_POSSIBLE_VISUAL_STUDIO_ROOT calls failing somehow?
The following code was disabled by you for wsl:
WINPATH_BASH="$BASH"
BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH([WINPATH_BASH])
Was it reading $BASH that was problematic, or the call to BASIC_WINDOWS_REWRITE_AS_WINDOWS_MIXED_PATH?
- The changes in escaping quotes in the env detection script, like: ECHO"ECHO "ECHO"WINPATH_BASH"' -c "echo VS_PATH=\""$PATH"\" >
set-vs-env.sh"'
makes me a bit nervous. Have you verified that this does not break on
cygwin, or with spaces in the path? I can no longer state exactly why it
looks the way it does, but I know that it's the effort of a lot of trial
and error on different platforms (cygwin and msys) and different
situations. Since we have no good way of running automatic tests for all
different platforms, changes such as these makes me nervous. That's not
saying that it's bad, but I'd like to see some extra testing.
This looks like some left-over debug output:
AC_MSG_NOTICE($VS_ENV_TMP_DIR)
And finally some replies to your mail:
On 2018-12-09 20:11, Andrew Luo wrote:
Hi Everyone,
I've been working on getting the OpenJDK to build on WSL (Windows Subsystem for Linux). Currently, our Windows build uses Cygwin. Given that WSL is provided with newer versions of the OS (and doesn't suffer from many of the issues that Cygwin does, given that it is built into the Windows kernel), I think it would be great if OpenJDK would support building on WSL. I've attached a patch with my proposed changes. One important thing to note is that the WSL build targets Windows. It is also possible to use WSL to target itself (a WSL Linux binary) or even other distributions of Linux. I have not implemented that yet, but I think I could do that as a next step if you guys think it would be useful (at least I think it would be useful, then you can test your changes for both Windows and Linux on one system...). I think if you just run configure ordinarily, it will behave like a Linux system and build the Linux image right out-of-the-box..? But then again, maybe that behavior is negated by your changes to config.guess and platform.m4. So maybe we need a flag to configure to control this... Steps in case you want to try this out:
1. Due to autotools not handling spaces well, you have to create symlinks in Windows that will allow you to access Windows Kits and the VC++ compiler without spaces in the path: mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio" mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits" That's a bit odd. We encounter spaces in paths on Windows normally on cygwin and msys, and that works fine. I suspect there is something missing with the rewriting functions. What we do, is that we rewrite paths with spaces to paths without spaces, by using the old 8+3 compatibility names, so we get something like "/cygdrive/c/progra
1/microso2" from "C:\Program Files (x86)\Microsoft Visual Studio". Have a look at BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL version of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you need to call the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.)
If you get these parts right, I don't think you will need any of the special instructions below to build. In fact, as long as C:... is properly remapped, the normal VS autodetect code should work just fine. And perhaps you can even revert some of the scarier changes in toolchain_windows.m4.
/Magnus
2. wsl must be started from a Windows Developer command prompt. To ensure the correct environment variables are propagated from Windows to WSL, you can run the following commands: set WSLENV=INCLUDE/l:LIBPATH/l 3. Start wsl (bash): wsl 4. After starting bash you must set your compiler variables to explicitly point to the correct tools: export AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/lib.exe export CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe export CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe export LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/link.exe export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe export DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/dumpbin.exe 5. Run configure: ./configure --with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1windows-x64bin/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
- Previous message (by thread): [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows
- Next message (by thread): [PATCH] Support for building using WSL (Windows Subsystem for Linux) on Windows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]