The job of a libc involves a lot more than just tracking the kernel APIs: it's got a malloc implementation, string handling, userspace buffered I/O and formatting, 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), user and group names and not just numeric IDs, DNS resolution, thread handling, math functions, etc. All of that is quite independent of your kernel and hewing closer to Linux doesn't help you with any of it - except maybe the thread stuff, and for that glibc is the standard pthread implementation for Linux so you're probably better off using it anyway since that's what the kernel developers expect. (In other words, libc is the C standard library, not the kernel's client library for its APIs.)

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. Even on Android, disk is cheap.

EGLIBC stands for Embedded GLIBC. That's a pretty good sign IMO that it was intended for embedded use.

The BSDs don't use glibc because of licensing concerns, not because they dislike glibc's bloat. (Their own libcs implement just as much, because programs use those features.) My claim upthread was that Android avoided glibc for licensing concerns, not for technical unsuitability; giving the BSDs as an example seems to agree with that argument.

> 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 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?

> 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?

If that were what happened, then you'd have an argument, but eglibc contained more than glibc did (the primary motivator was that glibc refused to support architectures that the maintainer didn't like; they also had patches to support compiling things out, but that's more source code and certainly isn't ripping anything out). If you don't know this history I have trouble taking the rest of your argument seriously.

> but eglibc contained more than glibc did

That "more" being "you can remove things." Straight from the project:

> EGLIBC's goals included reduced footprint

> A primary feature of EGLIBC is support for configurability. You can build EGLIBC without support for NIS, locales, or other things that you may not need in your embedded system.

So sure a full-fat EGLIBC was as big as GLIBC, but that was clearly not the point of making all the big stuff removable, and binary compatibility was not guaranteed as a result.

> the primary motivator was that glibc refused to support architectures that the maintainer didn't like

Given that reducing size is the first listed goal in both the opening description and the mission statements it seems like your claim is more about what you wish was true than anything else.

Furthermore the "why not contribute to GLIBC?" FAQ states "The GLIBC maintainers have stated that they wish to focus on server and workstation systems." Given servers with non-x86 architectures definitely exist (PowerPC says hello), along with GLIBC supporting an exhaustive list of architectures anyway, it seems this is really just about size after all. Unless your argument is GLIBC maintainers held a grudge against ARM specifically?