[BUG] make v4.4 seems to be picking binaries located last in my %PATH% order

[garoto]

Assuming it was the make upgrade.

Trying to compile https://github.com/andrei-drexler/ironwail/ ends with an error[0] but once I export a trimmed down PATH envvar[1], removing the cygwin compiled lftp dir from it, ironwail compilation succeeds.

To replicate: grab https://f001.backblazeb2.com/file/nwgat-cdn/lftp/win64/lftp-4.9.2.win64-openssl.zip, unzip it somewhere, add the path of the unzipped included ./bin/ dir to your %PATH%, restart/refresh your environment; grab ironwail's zipped src from the above linked repo, unzip, cd to the ./Quake subdir, and issue make -f Makefile.w64

This is not an issue in version 1.16.1.

[0]: https://i.imgur.com/u22hfZu.png [1]: https://i.imgur.com/HnNuxnF.png

The lftp binary I use ships with cygwin pre-compiled bins for sh.exe, bash.exe and ssh.exe.

[skeeto]

GNU Make may be searching for a suitable shell in a slightly different way than before, and so maybe prefers a shell it finds in Cygwin rather than w64devkit's "sh.exe". A Cygwin shell may pull part of the build into the Cygwin environment regardless of the order of PATH. An important hint from your screenshot is that error message from "bash.exe" indicating something is indeed invoking the wrong shell. There is no bash.exe in w64devkit, and nothing in Ironwail prioritizes it, so nothing should be running it.

In particular, GNU Make commit 7bb7bb4b made significant changes to path handling while searching for a shell, though I'm not spotting actual behavioral changes. Further, if I throw a dummy bash.exe in my PATH, ahead or behind w64devkit, I can't get GNU Make to pick it up no matter what I try, so I can't explain who's calling bash.exe in your screenshot.

Another suspicious detail is that "Generating dependencies ..." works but "Compiling ..." did not, failing due to a missing "gcc" command. However, both commands invoke "gcc" in almost exactly the same way. I'd expect both to succeed or both to fail at finding gcc. Like with bash.exe something is finding and invoking "/lftp/sh" for its shell even though it shouldn't.

I'm unable to reproduce the error in an artificial configuration, so it seems it's dependent on some complex interaction on your system. If you're able to build w64devkit yourself — all you need is Docker — you could try reverting to GNU Make 4.2 to confirm that's the difference.

$ git checkout v1.17.0 $ git revert 1000d8e $ ./multibuild.sh -q

That will produce a new "w64devkit.zip" to try.

Another thought: Assuming that's how you're building Ironwail, make sure build_cross_win64.sh is not invoked with a Cygwin shell. Either invoke it explicitly with the w64devkit shell, or even better, just don't use it at all. Use Makefile.w64 directly because w64devkit is already appropriately configured:

$ make -j -f Makefile.w64

Try that with the unchanged PATH if you haven't already.

Finally, check for a suspicious "SHELL" variable. Maybe that's pointing to Cygwin's bash.exe and so it's being used?

[garoto]

build w64devkit yourself — all you need is Docker [...]

I might try that, not familiar at all with Docker. Do you cross-compile w64devkit in a Linux environment?

Finally, check for a suspicious "SHELL" variable.

Nothing fancy there, just the regular busybox SHELL=/bin/sh env.

Although I don't think it's related (other than the $PATH thingy), but my Windows environment is sort of busy, so I might take the chance and clear it up via .profile before busyboxing. I've been postponing creating a trimmed down environment for busybox purposes for a while now.

[garoto]

Forgot to close the issue. Oops.