> but eglibc contained more than glibc did That "more" being "you can remove things." Straight from the project: > EGLIBC's goals included reduced footprint

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