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.
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.
Introduce a "system-wide" profile loaded before ~/.profile, and populate
it with variables to guide GNU Autoconf. In general, "configure" scripts
should now work out-of-the-box.
Libtool assumes the host environment is MSYS2 and will be confused by
Windows-style command switches. The "/c" in "cmd /c" looks like a path,
which MSYS2 incorrectly decodes to "c:/". Anticipating this, libtool
encodes these calls as "cmd //c" which does not work outside MSYS2. A
busybox-w32 patch makes it behave like MSYS2 in just this one case. This
patch has been upstreamed and will be removed on the next upgrade.
If CTRL-C terminates the alias but the child ignores CTRL-C, the parent
of the alias (shell, make, etc.) will be led to beleive the real command
terminated despite continuing to run. Because a null CTRL-C handler is
inherited, the alias sets a real handler that ignores all CTRL events,
relying on the child to make a decision. To minimize the window between
starting to ignore CTRL-C and spawning the child, SetConsoleCtrlHandler
is called as late as possible.
Often I want to examine the export and import tables of a module. The
best tool for the job (until now!) was MSVC dumpbin, but obviously it
cannot be distributed with w64devkit. Binutils objdump is inconvenient,
and it cannot reliably parse PE files that were not linked by ld (e.g.
Go binaries).
This new tool parses anytyhing, is more standalone, and more concise
than dumpbin, and much faster than both dumpbin and objdump. Exactly the
tool I've wanted for years.
This is the first Mingw-w64 release to default to UCRT. Since that was
anticipated in c17f5ca2, no changes are required. Though I worry about
the future for MSCVRT support. No longer default, fewer people will be
using it going forward.
Benefits for w64devkit:
* Updated gdtoa
* More Win32 API declarations
* Some new MSVC-related C++ overloads
https://www.mingw-w64.org/changelog/#v1200-2024-05-29
