Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

From what I understand the primary cause of fork/branch of EGLIBC as compared to GLIBC was the problem with patches for ARM that Debian devs wanted to push upstream.

I have slightly different question - is there any significant difference for relatively fat (as compared to embedded platforms) x86-64 machines?

share|improve this question
up vote 5 down vote accepted

The main goals of EGLIBC (described http://www.eglibc.org/mission) are all targeting embedded platforms:

  • Provide options to reduce on-disk and in-memory footprint: As long as you want to keep binary compatibility to glibc these options are useless or have nearly no effect on x86-64.
  • Support cross-compilation and cross-validation: Well... Who does cross-compiling for x86-64...
  • Support processors used in embedded systems: I guess you don't run "x86-64" embedded systems, so it's useless, too.
  • Incorporate support for processor-specific functionality where appropriate: glibc already has full optimizations for x86
  • Retain API and ABI compatability with GLIBC wherever feasible.

I wouldn't suggest using eglibc unless your distribution fully supports it, otherwise you may sometimes break linking when full ABI compatibility is not possible. Though, many developers criticize the development-style of glibc and so non-technical reasons may favor eglibc over glibc.

API and ABI compatibility between eglibc and glibc disallow big changes and all x86-64 optimizations are probably merged into glibc, too.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.