I've just done my first prerelease build of busybox-w32 with x86_64-w64-mingw32-gcc (version 16.0.1) on Fedora 44. The 32-bit binaries were fine, but the two x86_64 binaries were about 20KB larger than the last build on Fedora 43. The increase was entirely in the text section.
Looking at the sizes of the object files, most were about the same size as before but ~7% of them were a lot bigger. For example, the text section of libbb/trim.o went from 136 to 592 bytes. The assembly code seemed to indicate that the difference was a call to memmove being expanded into inline assembler. Apparently this is a thing.
OK, we can fix that: add -fno-builtin-memmove to the compiler flags at line 160 of Makefile.flags. And the size of the binaries goes back to normal.
I've tried the same thing with w64devkit's GCC 16.1.1 with the same effect.
Before:
$ x86_64-w64-mingw32-size.exe busybox.exe
text data bss dec hex filename
744588 1168 5616 751372 b770c busybox.exe
After:
$ x86_64-w64-mingw32-size busybox.exe
text data bss dec hex filename
724520 1168 5616 731304 b28a8 busybox.exe
Just thought you'd like to know.
I've just done my first prerelease build of busybox-w32 with x86_64-w64-mingw32-gcc (version 16.0.1) on Fedora 44. The 32-bit binaries were fine, but the two x86_64 binaries were about 20KB larger than the last build on Fedora 43. The increase was entirely in the text section.
Looking at the sizes of the object files, most were about the same size as before but ~7% of them were a lot bigger. For example, the text section of
libbb/trim.owent from 136 to 592 bytes. The assembly code seemed to indicate that the difference was a call tomemmovebeing expanded into inline assembler. Apparently this is a thing.OK, we can fix that: add
-fno-builtin-memmoveto the compiler flags at line 160 ofMakefile.flags. And the size of the binaries goes back to normal.I've tried the same thing with w64devkit's GCC 16.1.1 with the same effect.
Before:
After:
Just thought you'd like to know.