The following content is mainly historical; EGLIBC is no longer maintained or developed except for merges to the remaining active release branches.
Here are answers to frequently-asked questions about EGLIBC.
If you have additional questions, please send them
(along with suggested answers if you have them), to
Is EGLIBC a "fork" of GLIBC?
EGLIBC is not meant to be a fork of GLIBC. GLIBC is
well-suited to its core mission: providing a C library for
use on workstation and server GNU/Linux systems. However,
the GLIBC developers have requirements that make GLIBC
difficult to use on embedded systems. The goal of EGLIBC
is to provide a variant of GLIBC for use on embedded
systems, but with as few changes to GLIBC as possible.
Contributors to EGLIBC should consider contributing to GLIBC.
If the GLIBC maintainers accept the contribution, it will
find its way into EGLIBC because the EGLIBC maintainers
regularly merge GLIBC changes into EGLIBC. Because all changes
to EGLIBC meet the FSF's requirements for inclusion in GLIBC,
the GLIBC maintainers are always free to incorporate EGLIBC
Does EGLIBC have the same goals as
uClibc? How is EGLIBC different from uClibc?
uClibc does share a common goal with EGLIBC in that both projects
intend to provide a C library for use on embedded systems running
GNU/Linux. However, uClibc and EGLIBC are different in other ways.
First and foremost, uClibc is available today, and is already shipping on
a large number of systems. EGLIBC is a new project. If you need a small
C library today, uClibc is a better choice. The following
paragraphs refer to the goals for EGLIBC, not its current state.
uClibc is designed to be source compatible with GLIBC, but it is
not binary compatible. To use uClibc, you must recompile your
application. The EGLIBC maintainers hope that EGLIBC will be
binary compatible with GLIBC, in the sense that an application
compiled to use GLIBC can instead use EGLIBC without recompilation,
provided that the version of EGLIBC in use provides all of
routines required by the application.
When new functionality is added to GLIBC, it can be relatively easily
incorporated into EGLIBC, since EGLIBC is based on GLIBC. However,
adding the new functionality to uClibc can take more effort, since the
source bases are separate.
uClibc supports uClinux, whereas EGLIBC will likely only
work on GNU/Linux systems with an MMU.
Both uClibc and EGLIBC are free software, and both are licensed
under the Lesser GNU Public License (LGPL).
However, most code
in EGLIBC is assigned to the Free Software Foundation, or
is in the public domain. In contrast, the copyright for uClibc
is held by a variety of contributors.
Why is there a separate EGLIBC project? Why not just contribute patches
for embedded systems to GLIBC?
The GLIBC maintainers have stated that they wish to focus on server and
workstation systems. However, all code in EGLIBC is subject to the same
copyright assignment rules as GLIBC, and the EGLIBC stakeholders would be
more than happy to help merge the EGLIBC enhancements into GLIBC.
I don't work for an EGLIBC Consortium member. Can I still contribute code to EGLIBC?
Yes! The only prerequisite for contributing code to EGLIBC is that you assign
copyright interest in your changes to the Free Software Foundation. And, if
you cannot do that, you can still participate in discussions about EGLIBC.
How do people become EGLIBC maintainers? Do maintainers have to work for members of
the EGLIBC Consortium?
Maintainers must be nominated and approved by the EGLIBC Consortium. However,
maintainers need not work for a member of the EGLIBC Consortium. The members
are free to nominate any maintainer that they feel is well-qualified for