diff options
| -rw-r--r-- | docs/uclibc.org/FAQ.html | 77 |
1 files changed, 48 insertions, 29 deletions
diff --git a/docs/uclibc.org/FAQ.html b/docs/uclibc.org/FAQ.html index e9e3019cc..53cd52f88 100644 --- a/docs/uclibc.org/FAQ.html +++ b/docs/uclibc.org/FAQ.html @@ -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. |