single-binary for execline programs?

From: Dominique Martinet <>
Date: Wed, 1 Feb 2023 12:31:52 +0900


I'm currently having a fresh look at s6 on alpine (thanks for the recent
work with dynamic services! Looking forward to seeing it mature!).

One thing that surprised me is how many small executables the programs
come with.
In particular there's a "feature" with recent binutils that makes every
binary be at least 64KB on arm/aarch64[1], so the execline package is a
whopping 3.41MB[2] there (... and still 852KB on x86_64[3]) -- whereas
just doing a dummy sed to avoid conflict on main and bundling all .c
together in a single binary yields just 148KB (x86_64 but should be
similar on all archs -- we're talking x20 bloat from aarch64/armv7
sizes! Precious memory and disk space!)
I'm expectant that binutils will improve that ultimately, but it never
hurts to aim higher :)


It should be fairly easy to do something like coreutils'
--enable-single-binary without much modification, for example
compile each executable with -Dmain=main_$program and have a small
wrapper that forwards to main_$argv0 (or just rename if that becomes the
default behaviour right away, that'd be even simpler).
I would be happy to contribute to that if you're not against the idea.

In the long run this could also provide a workaround for conflicting
names, cf. old 2016 thread[4], if we'd prefer either running the
appropriate main directly or re-exec'ing into the current binary after
setting argv[0] appropriately for "builtins".
(I assume you wouldn't like the idea of not installing the individual
commands, but that'd become a possibility as well. I'm personally a bit
uncomfortable having something in $PATH for 'if' and other commands that
have historically been shell builtins, but have a different usage for


Received on Wed Feb 01 2023 - 04:31:52 CET

This archive was generated by hypermail 2.4.0 : Wed Feb 01 2023 - 04:32:39 CET