On Mon, 4 Jul 2022 16:26:21 GMT, Magnus Ihse Bursie <i...@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. > > I added some comments. As a minimum, you need to verify that this works on > WSL1, WSL2 and Cygwin. Ideally, you would test on msys2 as well. You will > need to verify that importing paths works for executables both with and > without .exe, both if they reside in the winenv root (like in /tmp) or on the > Windows drive (like /cygwin/d/data/...). > > As I wrote, I think you might run into problems for things like /tmp/foo.exe > on WSL1. It might also work on newer versions of wslpath but break on older, > seeing that Microsoft is in the habit of changing the behaviour of wslpath... Thanks @magicus for your comment! I thought we can remove `unixpath` to simplify fixpath in this patch, but we can use it to keep current behavior. So I updated this PR to use `unixpath`. Could you review again? It uses `test -e` instead of return code from wslpath. ------------- PR: https://git.openjdk.org/jdk/pull/9357
