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.
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.
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.
An increasing set of llama.cpp build configurations, particularly at
lower optimization levels, go just beyond COFF limitations and require
the "newer" bigobj COFF format in order to build.
It didn't quite work out-of-the-box because it needed server assets and
build-info.cpp. On my system, the generated files were left behind from
an old build, so I didn't notice.
The official llama.cpp CMake build has a bug where build-info.cpp is
generated in the original source tree, not the build directory, and so
concurrent out-of-tree builds race to produce incorrect binaries. This
makefile avoids a conflict by using a unique name.
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).
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.
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.
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/
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).
This library can be installed to a path with spaces, so all instances of
the prefix must be quoted. Though Autoconf does not support paths with
spaces and will not be able to use such installations.
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.
The only relevant changes for w64dk are in the Debugger Adapter
Protocol: process event, cancel request, attach request, and
dap-log-level configuration.
