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
While already possible using an ANSI escape sequence, the INI option
affords additional flexibility. It also supports wide titles, which
cannot be done with the busybox-w32 included in w64devkit. See #115.
To support this, I broke up homeconfig() into several functions to be
re-used and composed when handling the new option, such as expanding
environment variables. While doing so, I took the opportunity to remove
several maximum length limitations, like MAX_PATH, and so long paths are
now supported, at least as far as the launcher. I also simplified the
arena to a pair of pointers.
The program now sets $W64DEVKIT before loading the INI so that it is
available during variable expansion of titles.
If an especially large frame is requested, the low frame address might
overflow and land above the stack pointer, disabling the stack probe. In
practice it would only happen from alloca calls and VLAs using untrusted
sizes, but it would be nice to handle it anyway. This change introduces
an overflow check, nulling the low address and forcing the probe loop to
run until it overflows the stack.
In 64-bit (all) and 32-bit ___chkstk_ms, it costs a two-byte instruction
on the unhappy path, and on the fast path conversion of an unconditional
jump to a predictable conditional jump. On 32-bit __chkstk it costs two,
two-byte instructions, one on the fast path and one on the unhappy path.
Not too bad.
The stack low address "mov" did not need to move. I did it to keep the
stack frame operations together.
Thanks to Stefan Kanthak for pointing out this defect.
Binutils 2.36 made PIE mandatory, breaking gprof for all configurations,
so it was removed in c6ae1749. GCC 12 made PIE optional again, which
allows gprof to operate when linked with -no-pie. Closes#109.
Thanks to Felipe Garcia for catching this. That sub was a leftover from
an earlier version which did not push eax/rax. I missed it when updating
to the current version.
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.
LTO support on Windows is buggy, and occasionally I need to turn it off
(-fno-lto) to avoid problems, so just disable it entirely. Also shaves
about 9MiB off the distribution.
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.
This static library provides memset, memcpy, memmove, memcmp, and
strlen. The implementations are minimal wrappers around x86 string
instructions, making them both tiny (~26 bytes apiece) and reasonably
performant, though not nearly as fast as CRT implementations. I selected
these particular functions because GCC fabricates calls to each out of
thin air at some optimization levels. The first four are also genuinely
useful as built-ins (__builtin_memset, etc.), keeping in mind arbitrary
limitations with null.
Mingw-w64 does not implement them but instead offers imports from system
DLLs: -lmsvcrt, -lmsvcr120, -lucrt, -lntdllcrt. It creates a dependency
on a system DLL: practical, though unoptimal, and no licensing woes.
With -nostartfiles instead of -nostdlib, this happens implicitly.
MSVC provides static definitions in libvcuntime.lib, useful when cl or
clang-cl fabricates calls. They weigh several KB each, and require the
application or installer to present a EULA ("external end users to agree
to terms"). Not a great trade-off just for some basic memory functions.
In w64devkit, libmemory fills this role. It's a public domain library so
there are no license terms. Just add -lmemory to the build command. It
also allows liberal use of the associated built-ins, especially in debug
builds, which can benefit from fast memory operations despite -O0. MSVC
toolchains can also freely use libmemory.a, though it won't know how to
find it without help of course.
I do not plan to add more functions except for cases of GCC fabricating
calls (e.g. strlen). Certainly no null-terminated string functions.
i686-w64-mingw32 GDB 14.1 does not detect file changes. After rebuilds
it runs with stale debugging information and may put the target in an
invalid state. The user must either manually use the "file" command or
restart GDB in order to load changes. Mostly reverts f46b079.
In this release the --with-package options have broken further, and the
library detection scripts do not work at all. To workaround, toss these
options and manually place the include directory in CFLAGS, just as was
already necessary for LDFLAGS.
Cygwin fixes, no effect for w64devkit. The official release date was the
day following 11.0.0, on April 29th. However the project did not roll up
an actual, usable release until August 7th (today).
