Per comments in the GDB source, this warning is only supposed to be
shown once. Due to a bug it's shown every time, so just disable it
entirely. This affects Go targets, which is why it matters to me.
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).
The busybox-w32 alias binaries need not be unique. The command line
string contains all the necessary information, and busybox-w32 already
interprets that information properly. So just forward the command line
string to busybox.exe.
I also gave alias.c another tidying pass following my personal Windows
systems programming style. I'm sufficiently confident in this approach
that I feel it no longer requires apologetics. It speaks for itself. It
also now releases its "heap" before waiting on the target process.
While I'm at it, I also added a c89 command which is as "standard" as
the already-existing c99 command.
For ABI compatability, prior to -std=c++23 this method uses old inline
semantics. Because libstdc++ itself is not compiled as -std=c++23, it is
incompatible with -std=c++23 code using this method, even including some
libstdc++ headers like regex. However, it isn't obvious unless libstdc++
is statically linked, as it is in w64devkit. It's always been statically
linked, so ABI compatability across w64devkit releases is less important.
I've learned a lot since I wrote this two and half years ago. This was
one of my earliest serious attempts at building a CRT-free program, and
I had not yet learned the techniques to do so effectively. I lacked the
experience for dealing with certain common problems, and in some areas
approached it with the wrong mindset. For example, much of the original
program concerns tracking many little string lengths, which is finicky,
hard to follow, and difficult to modify. Better to operate in terms of
appending to buffers.
I also relied far too much on stack allocation, which has multiple
problems. First is friction with the toolchain. By default on Windows,
GCC inserts stack probes for frames larger than 4kiB in order to safely
commit more stack. Otherwise the program might skip the guard page. To
avoid this, I turned off probes and increased the committed stack size,
which requires multiple compiler/linker arguments. I'd like to avoid
that.
The second is that stack allocations have fixed, static sizes if you're
not using VLAs, which you're not if you're sane. So I need to figure out
and use the worst cast maximum sizes for everything. The stack has a
small, limited size, so I can't overestimate by too much either.
The third is that the stack remains committed until exit. There's no
giving it back before waiting on the long-lived shell process. It's
hardly anything, but I'd at least like the option.
All these problems are solved with region-based allocation. I get all
the nice stack semantics and lifetimes without any of the downsides. I
only really got the hang of arenas in the past couple years, which is
why I didn't use them in the original version. Now the entire program
probably uses under 1kiB of its stack.
I've also honed my style, in this case most notably in type names and
Win32 declarations. Along with no const, I find it much more readable
than the official names and style. As a bonus there's a nice, short
listing of all the required external functionality. This could be
plucked out as a .def file and used to build an import library, which
would eliminate the final dependency on Mingw-w64. Another major benefit
is faster build times. The new w64devkit.c cuts the build time by more
than 99%, merely by not including windows.h.
I've also learned other subtleties these past couple years:
1. GCC assumes the stack is 16-byte aligned, even on x86, but does not
guarantee 4-byte alignment, and such functions are usually called by
code not generated by GCC (e.g. called by Windows). This isn't only a
problem for CRT-free programs. It comes up most often with CreateThread,
and many GCC-compiled programs are subtly broken because of this. MSVC
and Clang do not have this issue.
2. GCC does not reliably generate correct code without -fno-builtin when
CRT-free, particularly for standard functions. Despite -fno-builtin, it
may generate calls to these functions, so sometimes you must provide
them. Clang also generates such calls despite being asked not to do so,
but it does not require -fno-builtin for correctness. You cannot even
ask MSVC not to call standard functions, but like Clang, it's careful
not to generate the wrong code for your own implementations. So always
use -fno-builtin with GCC when not linking a standard library.
3. While returning from the process entrypoint is technically valid and
generally works (in console applications), calling ExitProcess is more
robust and reliable. On Windows it's not uncommon for other processes to
meddle, including spawning uncooperative threads. These are bugs in the
other program, but they go unnoticed since virtually nothing actually
exits by returning from the entrypoint. It pays to play along.
4. In documentation, -nostartfiles is better than -nostdlib. It's
simpler and more fool-proof. When something's not working quite right,
it tends to quietly fill in the gaps. I still use -nostdlib in scripts
because it's stricter, and I can fix the problems that might arise.
* New shell variable: BB_OVERRIDE_APPLETS
* Improved diff handling of CRLF
* Numerous upstream BusyBox fixes
https://frippery.org/busybox/release-notes/FRP-5181.html
The shell now supports "set -/+o noconsole" but this change forces the
window one way or another on start, interfering with the natural window
state. The included patch restores the old behavior of doing nothing on
"+o noconsole" (default) and actively hiding it on "-o noconsole".
This release also introduces wide API support through a UTF-8 manifest,
disabled by default. Unfortunately the manifest breaks compatibility
with anything before Windows 10 release 1903 and the binary will not
load, so it will never be enabled in w64devkit. This was all possible
already using either an adjacent manifest (busybox.exe.manifest) or by
amending the binary with it later (MSVC mt.exe), along with a manual
change of code page.
My initial plan was to enable CONFIG_FEATURE_UTF8_{INPUT,OUTPUT} to
improve UTF-8 handling, then users could manually install an adjacent
manifest to enable full Unicode support. Perhaps eventually that step
could be automated, disabling/enabling the manifest dynamically just
before running the executable. However, interactive UTF-8 editing is
still too broken to be worth using or enabling. The editing buffer is
easily corrupted, leading to confusing results.
ConEmu injects a thread (ConEmuCD.dll) and injects a DLL that starts
threads (ConEmuHk.dll). These threads may linger after the main thread
has returned, delaying the process exit and even interfering with the
exit status. As a work around, call ExitProcess instead of returning
from the main thread. This terminates extra threads so that the process
will no longer wait for their voluntarily exit.
GDB's definition of "potentially dangerous" is far too broad. This
option creates substantial friction, discouraging debugger use, and
should be off by default.
The --with-arch=pentium4 keeps going under winpthreads because of the
matching context, which effectively disables it. One solution would be
to increase the context and deal with the extra conflicts. Instead
change the context so it doesn't match in the wrong place.
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.
