4 ms·
Sadly, real C standard libraries are anything but small. glibc is pretty huge; statically linking a simple hello world program produces something like 750KB of
by nneonneo 7y ago
Sadly, real C standard libraries are anything but small. glibc is pretty huge; statically linking a simple hello world program produces something like 750KB of output (libc.so itself is nearly 2MB in size). A quick peek at glibc's documentation shows just how much stuff there is: https://www.gnu.org/software/libc/manual/html_mono/libc.html https://www.gnu.org/software/libc/manual/html_mono/libc.html.
Unfortunately, I wouldn't call all of it critically useful stuff. For example, "strfry" and "memfrob" are useless beyond toy applications as neither are remotely secure; "l64a" and "a64l" are useless (and possibly even dangerous) because they look like they implement base64 but with a different alphabet (and a much worse API); they have a hilariously large number of random number generators, _none_ of which produce high-quality random numbers for simulation or especially cryptography; etc. etc.
Neither MSVC nor macOS will let you truly statically link a binary (because the system interfaces aren't constant), so it's harder to directly compare, but on macOS "libSystem.dylib" depends on basically everything in /usr/lib/system which is about 5MB of code.
So yeah, I don't think I'd call many real libc libraries "small" by any stretch.
- dottrap 7y agoHere is a web page comparing the different C library implementations: http://www.etalabs.net/compare_libcs.html http://www.etalabs.net/compare_libcs.html For the .a size: musl: 426k uClibc: 500k dietlibc: 120k If you statically link to these, your final binary will only pull what is actually needed and be smaller than this.
- BubRoss 7y agoI know they are smaller, but why are they able to only pull in what you use when other libc implementations can't?
- dottrap 7y agoAny that allows static linking will get the same benefit. For the three mentioned in the ancestor thread: Apple doesn't ship a static libc, so developers must dynamically link. glibc does allow static linking, but it is something they don't really go out of their way to promote and I recall some historic pains trying to get it to work right. Maybe that all works better today. MSVC does allow static linking to msvcrt. MSVC is a little different than other platforms because they have permutations (and associated rules) you must be aware of: [debug | release], [static | dynamic], [single-threaded | multithreaded].
- rurban 7y agoglibc is only so bloated because of locale und unicode support. Also 32bit wchar_t and intl errors. Adding better string functions or CPU-specific optims is nothing compared to that. musl is mostly so small because it only does the C locale and basic unicode towlower. Nothing like the monstruous glibc unicode tables or internationalized error messages.