RFR: 8289646: configure script failed on WSL [v3]

[Magnus Ihse Bursie]

On Tue, 5 Jul 2022 03:07:10 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> configure failed as following when I run it on WSL 1.
>> 
>> 
>> checking for version string... 20-internal-adhoc.yasuenag.jdk
>> configure: Found potential Boot JDK using configure arguments
>> configure: The command for java_to_test, which resolves as "/mnt/d/java/jdk-18/bin/java", can not be found.
>> configure: error: Cannot locate /mnt/d/java/jdk-18/bin/java
>> configure exiting with result code 1
>> 
>> 
>> fixpath.sh would attempt to add ".exe" (e.g. "java" -> "java.exe") if `wslpath -w" failed (returns non-zero value). However it returns zero even if the path does not exist in recent WSL (v0.61.4 at least).
>> 
>> WSL v0.60.0.0
>> 
>> $ wslpath -w silver-bullet
>> wslpath: silver-bullet: No such file or directory
>> $ echo $?
>> 1
>> 
>> 
>> WSL v0.61.4.0
>> 
>> $ wslpath -w silver-bullet
>> silver-bullet
>> $ echo $?
>> 0
>> 
>> 
>> We should add ".exe" at the tail of path regardless of return value from wslpath.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add to check unixpath existing

I'm talking about other files than executables. The path could be a data file, or a directory. It might not even exist; the import path function was written to be as tolerant as possible for stuff that seems to be a valid path but where only the initial part exists.

I'm worried that with the patch you are proposing, we will unconditinonally add `.exe` to any path that is not existing, which will make the next test fail (since then the path with the addition of `.exe` will most likely not exist either). In contrast, I believe the old code could accept stuff like /tmp/foo/bar, if /tmp/foo were a valid directory, but the file /tmp/foo/bar did not exist yet.

I don't have any ready access to a Windows machine right now (is on the verge of going on vacation for the summer), but can you verify that either:
1) the code prior to your fix would not accept a path like /tmp/foo/bar before, or that
2) your code will still accept it (this does not seem likely if I read the code correctly).

The problem that you are trying to solve is kind of the opposite of the solution you present. The issue is that wslpath is *too* permissive, accepting a path like /mnt/c/bin/git.exe when it should have returned false, making us retry with /mnt/c/bin/git.exe, which would then have succeeded.

So what you need to to is rather, if wslpath *succeeds*, try again with an .exe prefix, and if that *too* succeeds, use that instead. *And* you need to keep the current behavior, for old versions of WSL.

-------------

PR: https://git.openjdk.org/jdk/pull/9357