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.
The widl configure script is broken and does not support out-of-source
builds, so unlike gendef just above, it's built in the source tree. The
--prefix and --with-widl-includedir options must be congruent despite
their artificiality. These two paths are combined to construct the real
sysroot path at run time via tools.h:build_relative_path.
This patch also creates arch-prefixed aliases for both gendef and widl.
llvm-mingw switched to using it in this commit:
https://github.com/mstorsjo/llvm-mingw/commit/a96bbc0c
And I figured we should do the same. Especially since we download more
than just GNU make.
GNU themselves write (https://www.gnu.org/server/mirror.en.html):
> We recommend using this generic ftpmirror.gnu.org address wherever
> possible in links, documentation, etc., to reduce load on the main GNU
> server.
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.
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
Mingw-w64 stddef.h embeds a full, outdated copy of GCC stddef.h, which
overrides GCC's definitions, preventing GCC from defining C23 features
such as nullptr_t and unreachable(). This is a wrong. Ideally, Mingw-w64
ought not provide stddef.h because it has nothing to add. Despite this,
its header includes non-standard headers via crtdefs.h and defines quite
a bit more than it should. Other Mingw-w64 headers incorrectly rely on
these transitive includes. Rather than fix all these header bugs, allow
it to continue defining too much, and focus only on fixing C23.
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.
Both GMP and MPFR sometimes use the wrong compiler when cross-compiling
unless a compiler is explicitly chosen. GCC now defaults to C23, but the
GMP configure script uses old-style, pre-ANSI function declarations that
were removed in C23.
This extra layer serves no purpose. Removing it flattens out the
directory structure and makes it a little nicer. The mingw32.h patch
will need to be adjusted for GCC 15, as this file was renamed for the
upcoming ARM64 port.
This was supposed to be automatic, but libbacktrace's filetype.awk does
not recognize bigobj COFF (c9c9c07), and the detection failure overrides
--enable-stdcxx-backtrace. To work around it, clobber filetype.awk with
hardcoded output just before cross-compiling GCC.
Note: As of GCC 14.2, <stacktrace> requires linking -lstdc++exp.
Fixes#200.
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.
The ftp.vim.org subdomain is gone, but the server is still up under its
real hostname. No release artifacts prior to 9.0 are hosted at vim.org,
leaving only nluug.nl and its mirrors.
This format was introduced in VS 2005, and Binutils began supporting it
for x86-64 in 2013 and i386 in 2020. The format is now 20 years old and
well-established. An increasing amount of software is hitting the old,
meager COFF limitations. Rather than enable bigobj case-by-case, simply
switch to the new format by default.
This reduces compatibility with old linkers, but compatibility between
COFF toolchains has always been iffy. Even ignoring bigobj, Binutils and
MSVC link.exe already have limited object file compatibility for various
reasons.
A significant potential problem with changing the default is that the
Binutils developers didn't have the foresight to also add -mno-big-obj
at the same time, and so any change to the default at the very least
results in a flag day. This change does not introduce -mno-big-obj, so
it is not possible to produce objects in the old format.
This warning is new in Binutils 2.42, and it regards fixing a long-time,
x86 bfd bug. Previously the fixup did not occur and bfd would fail to
locate decorated symbols. In the case of an entry point, bfd silently
linked the wrong address! It remains silent if the entry point is not
found, but the fixup makes it more likely to find the symbol.
The old, buggy behavior was an accident. It differs from MSVC and nobody
wants it. Theoretically some program might depend on the old behavior,
hence the warning, but it's incredibly unlikely, so silence the warning.
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.
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.
