> When you statically link, only the functions that are actually called are included.
This is not true in general.
For this code:
#include <stdio.h>
int main(void)
{
puts("hello world\n");
return 0;
}
both GCC 7.3.0 and Clang 6.0.0[1] on my system generate an 828 KB binary when compiling with -static. The binary includes a whole bunch of stuff, including all the printf variants, many of the standard string functions, wide string functions, lots of vectorized memcpy variants, and a bunch of dlsym-related functions.
That's great, but can you now demonstrate the same with Qt and KDE, as you claimed above?
FWIW, I believe (but could very well be wrong) the reason that this works this well with MUSL is that every function is defined in its own translation unit. I doubt that Qt and KDE do that.
The library/project has to be designed right. Musl has dummy references that make static linking work without pulling in a bunch of junk. This is very much a language/project issue and I wish more languages actually looked at the huge mess of dep graphs that are needed for simple programs.
I think you will have better luck static linking against a different libc, like uClibc or musl libc. Statically linking against glibc doesn't work very well, and isn't supported by upstream.
uClibc and musl libc have much better support for static linking, and you will be able to make a much smaller binary with them than you would static linking against glibc.
This is not true in general.
For this code:
both GCC 7.3.0 and Clang 6.0.0[1] on my system generate an 828 KB binary when compiling with -static. The binary includes a whole bunch of stuff, including all the printf variants, many of the standard string functions, wide string functions, lots of vectorized memcpy variants, and a bunch of dlsym-related functions.By using -ffunction-sections -fdata-sections -Wl,--gc-sections (per https://news.ycombinator.com/item?id=19170667) I get this down to 804 KB. Still not quite what you suggest.
[1] Clang might just be using the same linker as GCC here, and you might blame including the extra stuff on the linker.