There is no benefit to downloading the tarballs within the container
using curl, especially since it doesn't have access to host certificates
and such.
* New programs: bc, crc32, free, nproc, sync, uptime
* Add Bash-style process substitution (i.e. <(...)) to the shell
* Improve shell stability
* ANSI escape support for printf
The 002 patch must be removed on the next update since it will already
be included.
This upgrade includes a patch that fixes a bug introduced at the last
minute on the upstream 2.37 branch. I submitted this patch upstream so
hopefully it will be fixed in a future release. If so, the patch should
be removed from w64devkit.
Due to GCC's upside-down configuration, the desired build options were
not being actually being applied to the cross-compiler itself. This fix
shaves another 7MB off the distribution zip.
Discovering all commands in PATH is painfully expensive (typically
several seconds) on Windows where file access is slow, so don't do it.
Worse, due to an alt-tab handling bug in the Windows console it's very
easy to activate this completion by accident.
This patch makes the BusyBox shell much more ergonomic for alt-tab heavy
workflows on Windows.
There's a regression in FRP-3902-g61e53aa93 that causes line editing to
get into a bad state and accumlate garbage characters. This release is
not in a usable condition, so revert to the previous release.
This introduces four new programs: bc, free, nproc, uptime. It also
significantly improves ANSI escape support for printf.
The SHELL=dash is a workaround for a bug in GNU Make. A patch has been
submitted upstream, so hopefully this can be removed later. The patch:
https://lists.sr.ht/~skeeto/public-inbox/patches/20756
Mingw-w64 v8.0.0 finally puts to rest the long-standing and irritating
issues with __USE_MINGW_ANSI_STDIO. As other distributions update they
will be on par with w64devkit on this point.
Msys2 supports optional static linking, and it does this well (though
optimized for speed, not size).
The "busybox --install" step has always been an unfortunate extra step
that I've watned to eliminate. I hoped I could do it via batch scripts
command "aliases". However, each aliased command has cmd.exe as its
parent interfering with its operation — particularly the disruptive and
infamous "Terminate batch job (Y/N)?" message which cannot be disabled.
The usual suggestion when people complain about this misfeature is to
use PowerShell. However, unlike batch scripts, PowerShell scripts are
not first class citizens on Windows. PowerShell is not always available
(often disabled by the adminstrator), and its scripts generally can't be
installed on and executed via the PATH, at least not without system-wide
configuration (i.e. PATHEXT).
The here is to use a tiny 4kB executable as a kind of crude compiled
shell script that, unlike cmd.exe, does the right thing. Since there are
so many, it adds about 150kB to the final .zip, but it does eliminate
this finall installation step.
Unlike batch script aliases, this program will be well-behaved and will
not produce a disruptive "Terminate batch job (Y/N)" prompt. The program
is always compiled freestanding in order to be as small as possible.
Interactive programs (vi, vim, gvim, vimtutor) are fine with a batch
script alias.
Since my busybox-w32 ash patch has been accepted upstream, BusyBox's
shell is now quite adequate and capable, so there's little reason to
consider a replacement shell at this point.
The windres --preprocessor command changed behavior in this release,
likely due to a bug, and it no longer word splits its argument (Binutils
commit 21c33bcb), though this was a misfeature to begin with. Vim uses
this option and so its build broke. Fortunately it doesn't actually need
to use --preprocessor sine the default is already fine, so it's been
removed.
This issue should be revisited on the next Binutils release.
About half the time I run fresh builds, at least one of the tarballs is
not downloaded correctly. The mirror is down, it has a bad certificate,
or it's serving HTTP 404 responses for files that should exist.