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.
This program is compiled many times, and 99% of the build time is GCC
parsing windows.h repeatedly. This macro trims the header and cuts the
build time almost in half, which will improve the overall w64devkit
build time.
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.
* 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.
