FAQ

About

Download

Development

Administration

The following content is historical; EGLIBC is no longer maintained or developed.

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 faq@eglibc.org.

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

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