UCRT is gradually growing in popularity, and it wasn't obvious from
README.md that w64devkit is a traditional MSVCRT toolchain.
The AVX issue comes up from time to time, just infrequently enough that
I need to rediscover the solution each time. Documentation in README.md
will be easier to find next time, warns those who haven't been bitten
yet, and documents the mitigation offline. Since it is unlikely to be
fixed any time soon, medium term I should figure out a small patch that
makes GCC only emit unaligned AVX moves. The penalty for unaligned moves
is 0% on newer processors and up to 10% on older ones. That's certainly
better than crashing due to a compilier bug.
https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/
Cuts the distribution size by around 60%, and unpacks around 100x faster
than Windows built-in .zip support. However, 7-zip is the worst packaged
project included so far. The source release is a tarbomb with a URL that
contains two variations of the release version. It is not designed for
cross-compilation, and so requires minor source corrections and a custom
build script. Still, considering the circumstances, it's surprising how
easily it compiles.
When I first put w64devkit together, there were incompatibilities with
Binutils and supporting gfortran was difficult. It's been stable for
years, and I want to simplify the download options.
I was initially impressed with its output, but over time I've found it
less and less useful. I hardly use it anymore, and it would at best be
neglected if left in the distribution. The build script is retained in
the contrib/ directory, and it's easy to build natively from source.
It's proven less useful than I originally hoped, and it's nearly always
better to use the GNU assembler instead. NASM doesn't support DWARF with
COFF, so it cannot be debugged with GDB. It's also ~100x slower than as,
which makes a huge different for generated assembly. With the autotools
fixes, it's now easy to natively build NASM from source using w64dk.
Provides 32-bit and 64-bit ___chkstk_ms and __chkstk. The former can
replace the libgcc implementation. Better license, about half the size,
and substantially faster when used on a hot path. The purpose and role
is similar to libmemory.
These new additions had not yet been documented, and are unlikely to be
discovered by chance. I dropped __USE_MINGW_ANSI_STDIO because now that
I've learned more I realized it has no practical use. If one cares about
this issue, one wouldn't use stdio in the first place, especially not
the particularly poor Microsoft stdio.
Despite appearances, the ">" operator is actually a pipe to Out-File,
and GetFileType() returns FILE_TYPE_PIPE for that handle. It is not
seekable and does not behave like a file. By default it re-encodes its
input, which is virtually always destructive, unwanted, and surprising.
Regardless of the wording in its documentation, it is not possible to
connect process output to a file, and PowerShell does not support file
redirection.
Cppcheck is a static analysis tool that's pretty easy to build and
include. Its "addons" are excluded since they depend on Python, as are
the "platforms" configuration since none of them are useful for Windows
applications. The "win32A" and "win32W" platforms are already embedded
within the tool.
It has a "FILESDIR" option to locate its configuration data. Relative
paths are unsupported, and so this feature is useless for a "portable"
Windows application. Fortunately it searches next to the executable, so
it can still find its configuration as long as it resides in the same
directory. These should not be in bin/, so build an alias to redirect
execution into share/.
This is yet another open source project that does not publish a stable
source tarball, so this build is likely to fail in the future when
GitHub changes its tarball layout. The --remote-header-name curl option
tells it to pick up the GitHub-provided name rather than use the request
path. Fortunately this doesn't seem to interfere with other downloads.
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.
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.
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.
As discussed in the README, this makes it easier for users to comply
with the Mingw-w64 licenses, and it's probably necessary for the
distribution itself anyway.
pthreads already works fine in C, so I assumed C++ threads worked.
However, it requires choosing POSIX, not Win32, threads during GCC's
configuration, which, in retrospect, makes sense.
Unfortunately Universal Ctags has never made an official release, and
the maintainer doesn't seem to be interesting in ever making one. So
there's no official stable tarball of the source code. GitHub's
automatically generated tarballs are not stable, so we can't use them.
So the best we can do is use a stable snapshot from a Linux
distribution, in this case Debian. This means we're limited to whatever
version Debian packages.
