Also switch to GitHub releases because it apparently not subject to
naive Expat security policies, making it more reliable. Expat only
parses trusted inputs in w64dk, and so is unaffected by security issues.
Updates are generally unnecessary. Unfortunately Expat's repository has
an unconventiontional tagging convention, and tags do not exactly match
the version, so the ARG will no longer work on its own, which is why I
had avoided its GitHub releases for so long.
One of my goals is that the distribution can be re-built in place using
only Docker or Podman, and so the unpacked distribution mirrors the
repository layout. That hasn't been true for w64devkit.ini, which is the
only file interfering with this trick, so fix it.
GNU Make incorrectly processes shell paths that contain a space on all
supported platforms. This is a common case on Windows after resolving
the shell's absolute path (e.g. "Documents and Settings" or "Program
Files"). The space is not escaped when constructing the shell command,
and then the shell path is truncated when splitting on the space.
Adding a space to sh_chars causes construct_command_argv_internal to
recurse indefinitely, so instead add a special case when copying the
shell path into the command.
My personal style has evolved slightly more, and so continue moving in
that direction:
* Just accept u8 as an aliasing type (it's tolerable)
* Capitalize struct and enum typedefs, but leave s8 and s16 unchanged
* -Wconversion compliance, both 32- and 64-bit
* iz/uz for sizes and pointer-integers
* i32 for flags
* -lmemory now that it's available, with memory built-ins
* Rely on w64devkit's unique stdcall patch
* Drop dangerously-broken GCC attributes (malloc, alloc_size)
* Use C23 [[...]] instead of __attribute (new and experimental!)
GUI Vim defaults to Fixedsys, a raster font which does not scale. On
HiDPI displays, Vim is unusable in its default configuration despite
supporting HiDPI generally. This issue was never solved upstream, and
the official Vim builds still have this poor experience. For w64dk, I
want a better out-of-the-box experience. It tries Consolas, present on
any HiDPI system, and then falls back to Fixedsys if necessary (XP). As
a side effect, the unicode experience improves as well because Fixedsys
has little support beyond ASCII.
There's an argument to be made for Lucida Console, but Consolas edges
out by not having a space in the name. This also "breaks the seal" on
making other changes to Vim's generally poor defaults, perhaps to adopt
some of neovim's more thoughtful defaults:
https://neovim.io/doc/user/vim_diff.html#defaults
3a38668f is incomplete, and requires the toolchain is located under a
path ending w64devkit/, which unfortunately made it into the 2.2.0
release. This patch is more complete, but must only be applied to the
native toolchain, not the cross toolchain, so it applies the patch late
in the build.
Remove 30k of Itanium demangling from C++ images just to display the
uncaught exception type before aborting. The message is near useless,
and GDB already does this while providing a wealth of information. An
application can still opt-in to the old behavior (including the 30k of
code) at runtime with:
std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
Speaking of GDB, std::terminate calls std::abort, but msvcrt!abort calls
exit() and does not trap. Introduce __gnu_cxx::__trap_terminate_handler
which uses __builtin_trap() instead, and set it as the new default. The
verbose handler also now uses a trap instruction. These changes improve
the debugging experience and better communicate the hard failure.
Closes#215.
The build used the host ar instead of the cross ar. With -mbig-obj as
the default (c9c9c073), the host ar cannot understand the PE32 object
files and so doesn't produce a symbol index. Not the first time this
problem has come up.
In bfd is a list of known libraries whose symbols are excluded when
exporting all symbols, the default behavior when no exports are chosen,
or with --export-all-symbols. The list is incomplete for w64dk and is
missing 15 additional "standard" libraries.
The result is that Windows-unaware builds using any of these libraries,
including any C++ program due to libpthread, tends to be broken. Instead
of adding each library to the list, blanket-exclude all libraries that
come from the sysroot. Since libpthread is so important, also add it to
the known list. Its absence is essentially a Binutils bug.
The original patch, which functioned properly between Bintuils 2.28
(March 2017) and 2.42 (January 2024), was broken by Binutils commit
057a2b4c (June 2024), made just 3 weeks later. Either rotten luck, or
someone's reading over my shoulder!
This GCC bug has had a wide impact since 2008. It affects nearly every
x86 program with a foreign-facing stdcall function, except WinMain and
wWinMain (covered by a CRT special case). That includes callbacks like
WNDPROC and APCs, thread procedures for CreateThread and _beginthreadex,
and entry points like mainCRTStartup and WinMainCRTStartup.
Programs included in w64dk have workarounds as needed, though between
Binutils 2.42 (6bf81ffd) and this patch, they're redundant. But still
needed, of course, when compiled with other Mingw-w64 toolchains.
Some cases are still affected, most commonly _beginthread, whose thread
procedure is _not_ stdcall, but is still called with a stack unsuitably
aligned for GCC. This case is less arguably a GCC bug, though neither
MSVC nor Clang are affected by this issue (due to not assuming 16-byte
stack alignment).
As of 3cacd962, the "known bugs" comment is no longer true for typical
use cases (x64 Windows 10 and later).
The UTF-8 comment came out of abusing GetPrivateProfileStringA. It was
replaced in 568efdcd with a custom parser.
The x86 build supports Windows XP, but the x64 build supports no earlier
than Windows 7 (my personal favorite). Windows XP outright rejects EXEs
with a UTF-8 manifest, but Windows 7 simply ignores it. That permits GCC
to continue operating on Windows 7 with a UTF-8 manifest (as of GCC 13),
which must be disabled entirely in x86 builds for Windows XP. The same
can be done with busybox-w32 by disabling the UTF-8 check and gracefully
degrading to original "ANSI-only" behavior when the manifest is ignored.
The UTF-8 manifest was added in GCC 13 but the configure switch was not
added until GCC 14 (https://gcc.gnu.org/PR111170). Better to use the
swtich rather than the original hack. Thanks to Peter0x44 for pointing
this out (#58).
