|
@@ -85,7 +85,7 @@ to the uClibc home page.</a>
|
|
|
</TD></TR>
|
|
|
<TR><TD BGCOLOR="#eeeee0">
|
|
|
|
|
|
- Initially, the project began since the GNU C library lacks support for
|
|
|
+ Initially, the project began since the GNU C library lacked support for
|
|
|
MMU-less systems, and because glibc is very large. The GNU C library is
|
|
|
designed with a very different set of goals then uClibc. The GNU C library
|
|
|
is a great piece of software, make no mistake. It is compliant with just
|
|
@@ -109,38 +109,46 @@ to the uClibc home page.</a>
|
|
|
</TD></TR>
|
|
|
<TR><TD BGCOLOR="#eeeee0">
|
|
|
|
|
|
- uClibc has been designed from the ground up to be a C library for embedded
|
|
|
- Linux. We don't need to worry about things like MS-DOS support, or BeOS,
|
|
|
- or AmigaOs any other system. This lets us cut out a lot of complexity and
|
|
|
- very carefully optimize for Linux. By very careful design, we can also
|
|
|
- take a few shortcuts.
|
|
|
-<!-- FIXME
|
|
|
- For example, glibc's stdio code (handling things
|
|
|
- like printf, scanf, fopen, etc) has been evolved over many years by
|
|
|
- patching various bits of additional functionality as needed. uClibc's
|
|
|
- stdio code was written by just one person, and was carefully designed from
|
|
|
- the outset to comply with the latest standards while carefully reusing code
|
|
|
- and being as small and configurable as possible, In this way, uClibc's
|
|
|
- stdio code...
|
|
|
-
|
|
|
- There are many similar examples.
|
|
|
--->
|
|
|
- In other cases, uClibc
|
|
|
- leaves certain features (such as full C99 Math library support, IPV6, and
|
|
|
- RPC support) disabled by default. Those features can be enabled for people
|
|
|
- that need them, but are otherwise disabled to save space.
|
|
|
+ uClibc and glibc have different goals. glibc strives for features
|
|
|
+ and performance, and is targeted for desktops and servers with
|
|
|
+ (these days) lots of resources. It also strives for ABI stability.
|
|
|
|
|
|
<p>
|
|
|
|
|
|
- Glibc is a general purpose C library, and so as policy things are optimized
|
|
|
- for speed. Most of uClibc's routines have been very carefully written to
|
|
|
- optimize them for size instead.
|
|
|
+ On the other hand, the goal of uClibc is to provide as much functionality
|
|
|
+ as possible in a small amount of space, and it is intended primarily for
|
|
|
+ embedded use. It is also highly configurable in supported features, at the
|
|
|
+ cost of ABI differences for different configurations. uClibc has been
|
|
|
+ designed from the ground up to be a C library for embedded Linux. We don't
|
|
|
+ need to worry about things like MS-DOS support, or BeOS, or AmigaOs any
|
|
|
+ other system. This lets us cut out a lot of complexity and very carefully
|
|
|
+ optimize for Linux.
|
|
|
+
|
|
|
+ <p>
|
|
|
+
|
|
|
+ In other cases, uClibc
|
|
|
+ leaves certain features (such as full C99 Math library support, wordexp,
|
|
|
+ IPV6, and RPC support) disabled by default. Those features can be enabled
|
|
|
+ for people that need them, but are otherwise disabled to save space.
|
|
|
+
|
|
|
+ <p>
|
|
|
+
|
|
|
+ Some of the space savings in uClibc is obtained at the cost of performance,
|
|
|
+ and some is due to sacrificing features. Much of it comes from aggressive
|
|
|
+ refactoring of code to eliminate redundancy. In regards to locale data,
|
|
|
+ elimination of redundant data storage resulted in substantial space
|
|
|
+ savings. The result is a libc that currently includes the features needed
|
|
|
+ by nearly all applications and yet is considerably smaller than glibc. To
|
|
|
+ compare "apples to apples", if you take uClibc and compile in locale data
|
|
|
+ for about 170 UTF-8 locales, then uClibc will take up about 570k. If you
|
|
|
+ take glibc and add in locale data for the same 170 UTF-8 locales, you will
|
|
|
+ need over 30MB!!!
|
|
|
|
|
|
<p>
|
|
|
|
|
|
The end result is a C library that will compile just about everything you
|
|
|
throw at it, that looks like glibc to application programs when you
|
|
|
- compile, but is many times smaller.
|
|
|
+ compile, and is many times smaller.
|
|
|
|
|
|
|
|
|
|
|
@@ -156,6 +164,8 @@ to the uClibc home page.</a>
|
|
|
If you are building an embedded Linux system and you are tight on space, then
|
|
|
using uClibc instead if glibc may be a very good idea.
|
|
|
|
|
|
+ <p>
|
|
|
+
|
|
|
If you are trying to build a huge fileserver for your company that will
|
|
|
have 12 Terabytes of storage, then using glibc may make more sense.
|
|
|
Unless, for example, that 12 Terabytes will be Network Attached Storage
|
|
@@ -201,7 +211,7 @@ to the uClibc home page.</a>
|
|
|
<p>
|
|
|
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
<B>
|
|
|
- Can I use it on my desktop i386 system?
|
|
|
+ Can I use it on my x86 development system?
|
|
|
</B>
|
|
|
</TD></TR>
|
|
|
<TR><TD BGCOLOR="#eeeee0">
|
|
@@ -403,9 +413,18 @@ to the uClibc home page.</a>
|
|
|
|
|
|
<p>
|
|
|
|
|
|
- These days, uClibc is being developed and enhanced by Erik Andersen of
|
|
|
- <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> along
|
|
|
- with the rest of the embedded Linux community.
|
|
|
+ In particular, around the end of 2000, Manuel Novoa III got involved with
|
|
|
+ uClibc. One of his first contributions was the original gcc wrapper.
|
|
|
+ Since then, he has written virtually all of the current uClibc stdio, time,
|
|
|
+ string, ctype, locale, and wchar-related code, as well as much of stdlib
|
|
|
+ and various other bits throught the library.
|
|
|
+
|
|
|
+ <p>
|
|
|
+
|
|
|
+ These days, uClibc is being developed and enhanced by Erik Andersen
|
|
|
+ and Manuel Novoa III of
|
|
|
+ <a href="http://codepoet-consulting.com/">CodePoet Consulting</a>
|
|
|
+ along with the rest of the embedded Linux community.
|
|
|
|
|
|
|
|
|
|