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?


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

  • I registered on red hat bugzilla but opening the link "You are not authorized to access bug #494758. Most likely the bug has been restricted for internal development processes and we cannot grant access.". Do you know there is another way to access these info ? thks, Massimo – Massimo Jul 20 '17 at 21:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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