4 ms·

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

by geofft 7y ago

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

kllrnohj 7y ago
> 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?

by geofft 7y ago

kllrnohj 7y ago

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