configure error on WSL 2

[Magnus Ihse Bursie]

On 2020-05-31 14:39, Yasumasa Suenaga wrote:
> Hi all,
>
> I tried to build jdk/jdk on WSL 2 with VS2019, but I saw three errors 
> as below.
>
>
> 1) Could not detect VC (cl.exe) version. So configure reports that it 
> could not find valid Microsoft C++ compiler.
>
> 2) Could not generate fixpath.exe because 
> $CONFIGURESUPPORT_OUTPUTDIR/bin did not exist. `wslpath -m` in 
> UTIL_REWRITE_AS_WINDOWS_MIXED_PATH - it does not seem to work with 
> unavailable path.
>
> 3) LPVOID value is passed to FormatMessage() in fixpath.c . 
> FormatMessage() accepts value for lpBuffer as LPTSTR.
>
>
> I think it is worth to fix. Someone already has worked for this?
I have been experimenting with building on WSL2. I've noticed the same 
issues as you have, but solved them somewhat differently. For instance, 
you cannot grep for "Optimizing Compiler" since this phrase is 
localized. We've had, and fixed, that bug before.

Incidentally, that fix is actually a workaround for what looks like a 
worrying issue in WSL2: race conditions on piping. Check this output:

magnusi at winihse:/mnt/c/localdata/hg/sandbox-ALT$ 
/mnt/c/jib/jib-ma~1/install/jpg/infra/buildd~1/devkit~2/vs2019~1.0/devkit~1.gz/vc/bin/x64/cl.exe 
2>&1 | cat
Microsoft (R) C/C++ Optimizing Compiler Version 19.25.28612 for x64
usage: cl [ option... ] filename... [ /link linkoption... ]
Copyright (C) Microsoft Corporation.  All rights reserved.

magnusi at winihse:/mnt/c/localdata/hg/sandbox-ALT$ 
/mnt/c/jib/jib-ma~1/install/jpg/infra/buildd~1/devkit~2/vs2019~1.0/devkit~1.gz/vc/bin/x64/cl.exe 
2>&1 | cat
usage: cl [ option... ] filename... [ /link linkoption... ]
Microsoft (R) C/C++ Optimizing Compiler Version 19.25.28612 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

magnusi at winihse:/mnt/c/localdata/hg/sandbox-ALT$ 
/mnt/c/jib/jib-ma~1/install/jpg/infra/buildd~1/devkit~2/vs2019~1.0/devkit~1.gz/vc/bin/x64/cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.25.28612 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]
magnusi at winihse:/mnt/c/localdata/hg/sandbox-ALT$ 
/mnt/c/jib/jib-ma~1/install/jpg/infra/buildd~1/devkit~2/vs2019~1.0/devkit~1.gz/vc/bin/x64/cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.25.28612 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

Notice how the order of lines are random when piping through cat. 
Worrying, indeed. I wonder what more will break...

Also, wslpath suddenyl not working with non-existing paths looks like a 
pure bug to me. :( But the correct workaround is not to go around and 
touch arbitrary files in the file system. For one thing, you might not 
have write permission there. I think the proper way (short of awaiting a 
bug fix from Microsoft) is to iteratively remove the last part of the 
path until wslpath succeeds, and then add back on what we removed.

Or we need to check how we are using wslpath. If it is used to verify if 
a file is present, we can use the failure from wslpath as a sign that 
the file is missing, instead of trying first to convert it to unix path, 
and then check if it is present.

---

However, the main problem when working with WSL2 is that it is dead 
slow, for building OpenJDK. :-( The method that was used in WSL1, to 
have the source code and build directory on a Windows share, is not 
working at all in WSL2. Access of NTFS drives has horrendous 
performance. :( On the flip side, WSL2 adds access to the Linux drive 
for Windows apps. So it might be possible to do the reverse -- make sure 
we store source and build directory on a Linux drive, and let the 
windows apps access it.

I have started testing this but have not had time to finish my testing. 
A lot of the Windows integration code in autoconf do not work  when you 
do this.

/Magnus

> If not, I will file it to JBS, and will send review request.
>
>
> Thanks,
>
> Yasumasa