Hello,
On 2018-12-10 02:06, Magnus Ihse Bursie wrote:
On 2018-12-09 20:11, Andrew Luo wrote:
One important thing to note is that the WSL build targets Windows.
It is also possible to use WSL to target itself (a WSL Linux binary)
or even other distributions of Linux. I have not implemented that
yet, but I think I could do that as a next step if you guys think it
would be useful (at least I think it would be useful, then you can
test your changes for both Windows and Linux on one system...).
I think if you just run configure ordinarily, it will behave like a
Linux system and build the Linux image right out-of-the-box..? But
then again, maybe that behavior is negated by your changes to
config.guess and platform.m4. So maybe we need a flag to configure to
control this...
It is indeed possible to build a pure Linux binary in WSL today so I
think it would be bad to lose that functionality. We certainly need a
configure flag to control if a Windows or Linux build should be produced
in this case. This is something I have been thinking about when I
started tackling WSL builds some time ago but didn't really come up with
a good solution. I didn't have the time to spend to really see it
through though, so it's nice to see that someone else is trying.
We could simply use the --with-openjdk-target, that would perhaps be the
cleanest, but it's also a bit cumbersome. We may need some
simplification similar to how we have --with-target-bits=32/64 as a
simple switch (e.g. --with-wsl-target=linux/windows?).
Steps in case you want to try this out:
1. Due to autotools not handling spaces well, you have to
create symlinks in Windows that will allow you to access Windows Kits
and the VC++ compiler without spaces in the path:
mklink /D C:\VS "C:\Program Files (x86)\Microsoft Visual Studio"
mklink /D C:\WindowsKits "C:\Program Files (x86)\Windows Kits"
That's a bit odd. We encounter spaces in paths on Windows normally on
cygwin and msys, and that works fine. I suspect there is something
missing with the rewriting functions. What we do, is that we rewrite
paths with spaces to paths without spaces, by using the old 8+3
compatibility names, so we get something like
"/cygdrive/c/progra~1/microso~2" from "C:\Program Files
(x86)\Microsoft Visual Studio". Have a look at
BASIC_MAKE_WINDOWS_SPACE_SAFE_CYGWIN. I think you need a WSL version
of that, as well as of BASIC_FIXUP_PATH_CYGWIN. (And you need to call
the BASIC_FIXUP_PATH_WSL from BASIC_FIXUP_PATH.)
If you get these parts right, I don't think you will need any of the
special instructions below to build. In fact, as long as C:\... is
properly remapped, the normal VS autodetect code should work just
fine. And perhaps you can even revert some of the scarier changes in
toolchain_windows.m4.
I definitely agree with Magnus that to make WSL truly supported, the
path handling macros need to be replicated. I'm not sure how to solve it
properly. The root path Magnus is asking for is not defined in WSL. In
fact, from windows you cannot reach any path in the WSL filesystem. Only
Windows drives are mounted in WSL, not the other way around. To convert
to old style paths in Cygwin we rely on the cygpath utility. There is a
wslpath utility but does it support old style path conversions? If not,
maybe it's possible to write such a tool in CMD/PowerShell?
/Erik
2. wsl must be started from a Windows Developer command
prompt. To ensure the correct environment variables are propagated
from Windows to WSL, you can run the following commands:
set WSLENV=INCLUDE/l:LIBPATH/l
3. Start wsl (bash):
wsl
4. After starting bash you must set your compiler variables to
explicitly point to the correct tools:
export
AR=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/lib.exe
export
CC=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe
export
CXX=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/cl.exe
export
LD=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/link.exe
export RC=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/rc.exe
export MT=/mnt/c/WindowsKits/10/bin/10.0.17763.0/x64/mt.exe
export
DUMPBIN=/mnt/c/VS/2017/Enterprise/VC/Tools/MSVC/14.16.27023/bin/Hostx64/x64/dumpbin.exe
5. Run configure:
./configure
--with-boot-jdk=/mnt/c/Users/Andrew/Downloads/openjdk-11.0.1_windows-x64_bin/jdk-11.0.1
--with-tools-dir="C:\VS\2017\Enterprise\VC\Auxiliary"
--with-ucrt-dll-dir="/mnt/c/WindowsKits/10/Redist/ucrt/DLLs/x64"
6. Run make
I've tested make with the default target as well as "make images"
Let me know if you have any feedback/comments.
Thanks,
-Andrew
