After the growth of various dependencies, the added weight of a C++
toolchain has become relatively small. I no longer feel it's worth
including as a separate variant.
Despite appearances, the ">" operator is actually a pipe to Out-File,
and GetFileType() returns FILE_TYPE_PIPE for that handle. It is not
seekable and does not behave like a file. By default it re-encodes its
input, which is virtually always destructive, unwanted, and surprising.
Regardless of the wording in its documentation, it is not possible to
connect process output to a file, and PowerShell does not support file
redirection.
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.
Programs with main typically also have mainCRTStartup, but it's unlikely
that the user wants to break inside the CRT. If WinMain or wWinMain are
present, the user purposefully defined them, so prioritize those even
higher.
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.
I've gotten a lot better at CRT-free since I first wrote this. I'm more
confident about this version, it produces better error messages, and it
compiles around 10x faster. The last point matters because w64devkit
currently compiles this program 181 times.
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.
