These options are autoconf-generated and unused by Binutils. Not only do
they not do anything useful, but worse, they cause incorrect Binutils
builds. Plugins, which are supposed to be dynamically-loaded, instead
become useless, static archives.
Fixes#13.
Sets the baseline to circa 2000, and specifically takes advantage of
SSE2. GFortran in particular generates far better code when at least
SSE2 is available, rather than relying entirely on x87.
When this manifest present, ctags.exe is no longer a valid executable on
Windows XP. Since this manifest doesn't do anything useful anyway, just
remove it.
The "releases" section needs emphasis since GitHub doesn't give it good
visiblitiy, and lots of people seem to miss it. Also, in the time since
w64devkit came about, Mingw-w64 itself and other distributions have
improved, picking up features once unique to w64devkit. The previous
claims are less strong now.
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.
