> locales (quite a bit more important on a phone targeted at consumers around the world than on servers whose sysadmins generally prefer messages in English to

> locales (quite a bit more important on a phone targeted at consumers around the world than on servers whose sysadmins generally prefer messages in English to their native tongue anyway) This is part of where glibc's bloat comes from. Locales are important, yes, but when your libc's versions are bad and you have to ship an alternative anyway (icu4c), then the one in glibc is just pure, wasted bloat. But ignoring that aspect since not every program needs internationalization, this just becomes bloat in the libc. This is really not something a libc (or any standard library) should be handling. Even if it's just because it's an area that moves too fast for a standard library to typically keep up with, and needs a faster deployment cycle. > Bloat in terms of amount of code is a confusing argument: you map libraries from disk, so you only use memory for the pages of code that have actually been read from disk and you only use one copy regardless of how many programs are running. You could add a function to glibc to print War and Peace to the screen and the only thing it would do is add a few megabytes of disk usage if nobody called it. Not entirely true. You're assuming everyone is using a single shared version, which isn't universally true. Some need static for reasons, and there's multiple shared versions not one for 32bit vs. 64bit or strict versioning requirements. Also not all functions are free to add. __attribute__((constructor)) exists, after all, and is hugely not free of course. Similarly pages are not purely loaded on-demand, they are prefetched. Depending on where you've added those functions and how the resulting layout happened, you may now be getting fewer prefetch hits than you did before. > Even on Android, disk is cheap. No, not really. Today is the size of glibc less important? Maybe, sure. Was that true back in the Android 1.0 days? No. There are some numbers here: http://www.etalabs.net/compare_libcs.html http://www.etalabs.net/compare_libcs.html glibc is stonking massive compared to what a C library really needs to do and, critically, has the largest minimum dirty page sizes. That's a shared library creating not-shared memory usage. > EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was intended for embedded use. Someone forked GLIBC and ripped a bunch of stuff out and you're taking that as a good sign GLIBC was intended for embedded use? What?