5

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?

1 Answer 1

5

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.

1
  • 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, 2017 at 21:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .