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 don't get it, you are saying that in mainline you get no warning but with your patch you get a warning, and yet you claim behavior is the same?

On one hand, it seems like the latter behavior is indeed more correct, if you pass a path that do not exist. (And I'm curious as to why this warning did not trigger in mainline?)

But, in our configure script, we are not calling `fixpath import` with the `-q` option, so this new warning will leak through. I think we ought to use `-q`, though, and I was a bit surprised at noticing that we do not. 

So, it seems that the warning is warranted and we should be able to cope with it, but I don't understand why it does not show up in mainline, and I am worried about changing the behavior.

And overall, I still think it sounds like a risky and not really warranted behavior to unconditionally add .exe, regardless of if this file exists or not, and then hope that this will fail later on if it does not exists. What is your rationale for *not* verifying the presence of the .exe version before adding the extension?

I'm sorry I'm so anti, it's just that we have severely lacking methods of verifying the correctness of fixpath.sh, and historically even the most innocuous changes in path conversion on Windows have lead to breakage in odd circumstances, so I'm naturally extremely conservative about changes here.

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

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