Ron Yorston

It bothered me that the binaries generated using w64devkit were so much larger than the ones cross-compiled on Linux. The issue is with the compiler feature tests in ```scripts/Kbuild.include```. These...

I've reverted the changes that were causing w64devkit builds of busybox-w32 to fail when run from a drive other than the system drive. The latest [prerelease binary](https://frippery.org/files/busybox/prerelease) has this adjustment.

>w64devkit now works at any drive letter, but not strictly out of the box. The busybox-w32 binary that comes with w64devkit is a specially tailored version with some applets disabled...

Another revision of the patch to fix some more things that bothered me: ~~[w64devkit-build-busybox-v4.txt](https://github.com/rmyorston/busybox-w32/files/9877364/w64devkit-build-busybox-v4.txt)~~ [w64devkit-build-busybox-v5.txt](https://github.com/rmyorston/busybox-w32/files/9880934/w64devkit-build-busybox-v5.txt) - Once a binary had been built changing any file would cause a complete rebuild,...

The latest code in git builds in w64devkit without patching. It also fixes a problem that broke the build in MSYS2. @Hawk2811 Sorry your issue has been hijacked by spam...

Of course, I don't know _exactly_ what you're trying to do, but do you need the outer quotes?

Never mind the additional complication of running ```mklink``` from a shell function: are there _any_ circumstances in which a command being run via ```cmd /c``` can have arguments containing whitespace?

Yes, I know why the quotes are needed. The problem is getting ```cmd.exe``` to see them. I think the ```/s``` option helps: ```cmd /s /c mklink /j "${1:?}" "${2:?}"```

We don't want to _see_ the quotes, we want them to allow whitespace in arguments. ``` ~ $ create_junction() { > cmd /s /c mklink /j "${1:?}" "${2:?}" > }...

Ah yes, forward slashes are used to introduce options in Windows. I guess the space in my example prevented ```mklink``` from seeing the first forward slash as an option. BusyBox...