Unfortunately this does not work as well as I had hoped. If the debugee
is currently paused in a debug event, it will not be terminated until it
continues. The whole point of this tool is to be quick, convenient, and
thoughtless, but mentally tracking the debugee state is extra cognitive
load. Might as well just get in the habit of killing the process from
the debugger, even if it requires running debugbreak first.
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.
* New "jn" command for creating Win32 junctions
* New environment variable $BB_OVERRIDE_APPLETS
* Improved "ls" metadata listings
* Improved "which" command
* Use existing $HOME on login shell startup
* "date" command now supports nanoseconds (%N)
* Improved unix-style executable path handling
* Various bug fixes
https://frippery.org/busybox/release-notes/FRP-4716.html
For w64devkit, I decided to omit the new "tsort" from upstream BusyBox.
The "link" command conflicts with MSVC (i.e. vcvars.bat), blocking some
access to its linker. Since this command is a subset of "ln" it does not
need to exist. The related "unlink" command is similarly redundant.
This is not documented as thoroughly as it should be, but XML support is
necessary for debugging across DLL boundaries, including even stepping
over DLL functions without getting lost. This is a significant upgrade
to GDB.
libgfortran now prefers clock_gettime before gettimeofday. Mingw-w64
supplies clock_gettime via winpthreads, so it must be installed before
building libgfortran.
The sysroot should include the architecture triple. With the wrong
sysroot, ld couldn't find the Mingw-w64 libraries. This makes it easier
to work with assembly programs.
Neither are needed and they each add kB of weight to executables due to
alignment requirements. Most of it compresses away, but excluding them
still shrinks the overall w64devkit .zip by a few kB.
Since it's designed to be isolated, w64devkit shouldn't pick up system
configuration like this. Besides, GCC's manual says, "Vendors and
distributors who use custom installers are encouraged to provide a
different key" but I don't plan to do so.
IMPORTANT: In this release _WIN32_WINNT is changed from 0x502 to 0xa00.
GDB: The Autoconf check for bcrypt.h in the embedded Gnulib is broken
and probably never worked in the first place, so Gnulib never tries to
use this header. When the check fails, it then checks if it's safe to
link against bcrypt.dll based on the value of _WIN32_WINNT. Before
Mingw-w64 9.0.0, this check also failed. So it used a run-time dynamic
symbol lookup fallback. However, if the version check succeeds, which it
does with 9.0.0, Gnulib incorrectly links bcrypt.dll, resulting in a
build failure.
In typical GNU fashion, Gnulib uses 187 lines of code to do something
poorly where 7 lines of code would do it well. Instead of hacking around
BCryptGenRandom, Gnulib should just call RtlGenRandom. This could be a
whole lot simpler and less fragile.
busybox-w32: The higher _WIN32_WINNT value causes new declarations to
become visible which conflict with definitions in busybox-w32, mostly in
networking headers like winsock2.h. To workaround it, lock it to the old
version.
These options are autoconf-generated and unused by Binutils. Not only do
they not do anything useful, but worse, they cause incorrect Binutils
builds. Plugins, which are supposed to be dynamically-loaded, instead
become useless, static archives.
Fixes#13.
Sets the baseline to circa 2000, and specifically takes advantage of
SSE2. GFortran in particular generates far better code when at least
SSE2 is available, rather than relying entirely on x87.
