The Mingw-w64 default may change to UCRT in the future, possibly soon,
but w64devkit will continue with the original msvcrt.dll for as long as
possible. It has far better compatibility with older systems, and UCRT
has limited availability prior to Windows 10.
The only benefits of linking UCRT that I know are better compatibility
when statically linking with UCRT-based toolchains, particularly MSVC,
and actually-working assertions (something Mingw-w64 could fix, as it
does printf, etc.). That's it! Mingw-w64 already fills in the missing
C99 bits. The Mingw-w64 documentation vaguely mentions a UTF-8 locale,
but it is either false or useless depending on the meaning. UCRT has all
the same narrow API limitations of MSVCRT — *the* biggest and thorniest
issue with Windows CRTs.
Trading away a ton of backwards compatibility just for better static
linking with MSVC sounds like a poor cost-benefit trade-off. In that
light, the choice of CRT seems obvious regardless of the Mingw-w64
default. My own view is that Windows CRTs have been poorly implemented
and are generally not worth using, so they should be avoided in the
first place, i.e. define {main,WinMain}CRTStartup, call Win32 directly,
and compile with -nostartfiles.
https://sourceforge.net/p/mingw-w64/mailman/message/37853546/
As of GDB 13.1, gdb.exe contains data triggering a bug in x64 Explorer
zip integration at last as far back as Windows 7. After recompressing
with advzip, gdb.exe extraction fails with 0x80004005 "Unspecified
error". This happens with both 32-bit and 64-bit gdb.exe regardless of
compiler flags. No other zip program has trouble with this file.
Until this is resolved, give up on advzip and tell zip to use -9. Also
renamed the build script option from -q (quick) to -O (optimize) and
disable its use by default.
Windows programs have several conventional entry points depending on
various circumstances. Upstream GDB is only aware of "main" and the
"start" command behaves poorly or incorrectly otherwise.
This is the first official versioned release of Universal Ctags, dated
December 2022. There were no prior tagged releases, let alone stable
source tarballs, so w64devkit piggy-backed off Debian's fork for the
needed stability.
This release has an official, stable source tarball, but it's broken and
practically useless. Further, the Git repository isn't tagged correctly,
having no annotated tags even for 6.0.0. Fortunately GitHub has recently
committed to generating stable source tarballs following backlash from
archive breakage in early February 2023. Because GitHub's source tarball
is more reliable than the official tarball, use it instead.
As of GDB 12.1, libiconv is a mandatory dependency on Windows. As with
Expat, this fact is undocumented. GDB builds successfully without but
that build is broken and practically useless. This dependency introduces
no new features nor makes GDB work better (i.e. GDB still cannot display
non-ASCII strings). It is necessary only to retain the capabilities
already present in GDB 11 an earlier.
This introduces yet another dependency, but it's a substantial gain for
a small cost.
GDB lacks "--with-libcurses-prefix" so I had to manually list the path
in LDFLAGS. Otherwise the GDB configure script fails to find waddstr and
gives up even though actually linking gdb.exe works fine without it.
The capitalized file name for PDCurses introduces a small sorting issue
in SHA256SUMS. Lexicographic collation with PDCurses at the top? A more
natural collation with PDCurses in the middle? I generate the listing
via "sha256sum *" in Bash, and in my locale Bash uses the latter, so
that's what I'll use.
Obviously elfedit and readelf are not useful on Windows. GProf has not
worked on Windows since Binutils 2.36 because it doesn't support PIE. It
was never effective in the first place, so it probably wasn't ever worth
including.
In the future I plan to call these "CRT-free" rather than "freestanding"
since it is more accurate. This approach has been trial-and-error due to
its unusual nature, the lack of convention, non-existing documentation,
and poor implicit defaults in the GNU toolchain. After spending time
navigating the problem space and discovering its pitfalls, I understand
much better how to construct these binaries. The changes at a high level
and their reasoning:
Avoid -ffreestanding since this is not really its purpose. It may still
be necessary to use -fno-builtin to prevent certain CRT calls.
Replace -fno-ident with -Wl,--gc-sections. It accomplishes the same and
much more. Even better, it is only needed at link time.
Do not qualify mainCRTStartup with WINAPI. By default, the GNU linker
looks for this symbol as the entry point. Not finding one, it silently
chooses the beginning of the .text section as the entry point. Marked
WINAPI, it gets __stdcall-decorated on i686 and is no longer recognized
by the linker. In the past I have been lucky that "main" happened to be
the first function in .text, so this worked out. This is incompatible
with the MSVC toolchain (an oversight in MinGW / Mingw-w64) since it is
explicitly documented that the entry point uses __stdcall. Since there
are no arguments, __stdcall and __cdecl happen to be identical, which is
why nobody notices.
Alternatively I could use -Wl,--entry= to choose an entry point, which
at least produces a warning when the symbol is not found. However, this
accepts the decorated symbol name, and so the exact invocation depends
on the target: i686 or x86-64. Rather inconvenient. The implicit search
for mainCRTStartup resolves this automatically, except when __stdcall is
involved, per above.
If using more than two pages of local variables in any function, you
must disable the stack probe with -mno-stack-arg-probe because the probe
is provided by the CRT. Normally the stack grows with use, and the probe
handles large stack frames that may jump the guard page. Instead commit
a larger stack at startup: "-Xlinker --stack=Z,Z" where Z is the desired
size, e.g. use 0x100000 to commit a 1MiB stack.
The one-shot command works, but only use a single core. This build
benefits significantly from parallelization, and make is the easiest way
to do it. Since the original Cppcheck makefile doesn't do the right
thing, supply a custom build.
Even the latest GDB release does not correctly support DWARF 5 from GCC,
most notably preprocessor macros. This is a bug in either GCC or GDB and
is present across every platform tested. DWARF 4 works fine, so stick to
it for now.
Cppcheck is a static analysis tool that's pretty easy to build and
include. Its "addons" are excluded since they depend on Python, as are
the "platforms" configuration since none of them are useful for Windows
applications. The "win32A" and "win32W" platforms are already embedded
within the tool.
It has a "FILESDIR" option to locate its configuration data. Relative
paths are unsupported, and so this feature is useless for a "portable"
Windows application. Fortunately it searches next to the executable, so
it can still find its configuration as long as it resides in the same
directory. These should not be in bin/, so build an alias to redirect
execution into share/.
This is yet another open source project that does not publish a stable
source tarball, so this build is likely to fail in the future when
GitHub changes its tarball layout. The --remote-header-name curl option
tells it to pick up the GitHub-provided name rather than use the request
path. Fortunately this doesn't seem to interfere with other downloads.
Vim is substantially smaller because vim.exe and gvim.exe are now
effectively the same binary. On Windows these must be distinct binaries
since they target the "console" and "windows" subsystems separately.
"vim -g" now works correctly, though "vim -g -f" still does not work.
Enabling VIMDLL requires enabling IME (probably a bug). I also noticed
vimrun.exe isn't stripped, nor does it need to be installed on the PATH.
When a console process under GDB is stuck in a loop, it's difficult to
break the program without also killing GDB. This utility can be run from
another console, or even Vim, to cause the debuggee to break.
