uClibc和Glibc区别

uClibc and Glibc are not the same -- there are a number of differences which
may or may not cause you problems.  This document attempts to list these
differences and, when completed, will contain a full list of all relevant
differences.
1) uClibc is smaller than glibc.  We attempt to maintain a glibc compatible
interface, allowing applications that compile with glibc to easily compile with
uClibc.  However, we do not include _everything_ that glibc includes, and
therefore some applications may not compile.  If this happens to you, please
report the failure to the uclibc mailing list, with detailed error messages.
2) uClibc is much more configurable then glibc.  This means that a developer
may have compiled uClibc in such a way that significant amounts of
functionality have been omitted.
3) uClibc does not even attempt to ensure binary compatibility across releases.
When a new version of uClibc is released, you may or may not need to recompile
all your binaries.
4) malloc(0) in glibc returns a valid pointer to something(!?!?) while in
uClibc calling malloc(0) returns a NULL.  The behavior of malloc(0) is listed
as implementation-defined by SuSv3, so both libraries are equally correct.
This difference also applies to realloc(NULL, 0).  I personally feel glibc's
behavior is not particularly safe.  To enable glibc behavior, one has to
explicitly enable the MALLOC_GLIBC_COMPAT option.
4.1) glibc's malloc() implementation has behavior that is tunable via the
MALLOC_CHECK_ environment variable.  This is primarily used to provide extra
malloc debugging features.  These extended malloc debugging features are not
available within uClibc.  There are many good malloc debugging libraries
available for Linux (dmalloc, electric fence, valgrind, etc) that work much
better than the glibc extended malloc debugging.  So our omitting this
functionality from uClibc is not a great loss.
5) uClibc does not provide a database library (libdb).
6) uClibc does not support NSS (/lib/libnss_*), which allows glibc to easily
support various methods of authentication and DNS resolution.  uClibc only
supports flat password files and shadow password files for storing
authentication information.  If you need something more complex than this,
you can compile and install pam.
7) uClibc's libresolv is only a stub.  Some, but not all of the functionality
provided by glibc's libresolv is provided internal to uClibc.  Other functions
are not at all implemented.
8) libnsl provides support for Network Information Service (NIS) which was
originally called "Yellow Pages" or "YP", which is an extension of RPC invented
by Sun to share Unix password files over the network.  I personally think NIS
is an evil abomination and should not be used.  These days, using ldap is much
more effective mechanism for doing the same thing.  uClibc provides a stub
libnsl, but has no actual support for Network Information Service (NIS).
We therefore, also do not provide any of the headers files provided by glibc
under /usr/include/rpcsvc.
9) uClibc's locale support is not 100% complete yet.  We are working on it.
10) uClibc's math library only supports long double as inlines, and even
then the long double support is quite limited.  Also, very few of the
float math functions are implemented.  Stick with double and you should
be just fine.
11) uClibc's libcrypt does not support the reentrant crypt_r, setkey_r and
encrypt_r, since these are not required by SuSv3.
12) uClibc directly uses kernel types to define most opaque data types.
13) uClibc directly uses the linux kernel's arch specific 'stuct stat'.
14) uClibc's librt library currently lacks all aio routines, all clock
    routines, and all shm routines (only the timer routines and the mq
    routines are implemented).
******************************  Manuel's Notes  ******************************
Some general comments...
The intended target for all my uClibc code is ANSI/ISO C99 and SUSv3
compliance.  While some glibc extensions are present, many will eventually
be configurable.  Also, even when present, the glibc-like extensions may
differ slightly or be more restrictive than the native glibc counterparts.
They are primarily meant to be porting _aides_ and not necessarily
drop-in replacements.
Now for some details...
time functions
--------------
1) Leap seconds are not supported.
2) /etc/timezone and the whole zoneinfo directory tree are not supported.
   To set the timezone, set the TZ environment variable as specified in
   
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html
   or you may also create an /etc/TZ file of a single line, ending with a
   newline, containing the TZ setting.  For example
   echo CST6CDT > /etc/TZ
3) Currently, locale specific eras and alternate digits are not supported.
   They are on my TODO list.
wide char support
-----------------
1) The only multibyte encoding currently supported is UTF-8.  The various
   ISO-8859-* encodings are (optionally) supported.  The internal
   representation of wchar's is assumed to be 31 bit unicode values in
   native endian representation.  Also, the underlying char encoding is
   assumed to match ASCII in the range 0-0x7f.
2) In the next iteration of locale support, I plan to add support for
   (at least some) other multibyte encodings.
locale support
--------------
1) The target for support is SUSv3 locale functionality.  While nl_langinfo
   has been extended, similar to glibc, it only returns values for related
   locale entries.
2) Currently, all SUSv3 libc locale functionality should be implemented
   except for wcsftime and collating item support in regex.
stdio
-----
1) Conversion of large magnitude floating-point values by printf suffers a loss
   of precision due to the algorithm used.
2) uClibc's printf is much stricter than glibcs, especially regarding positional
   args.  The entire format string is parsed first and an error is returned if
   a problem is detected.  In locales other than C, the format string is checked
   to be a valid multibyte sequence as well.  Also, currently at most 10 positional
   args are allowed (although this is configurable).
3) BUFSIZ is configurable, but no attempt is made at automatic tuning of internal
   buffer sizes for stdio streams.  In fact, the stdio code in general sacrifices
   sophistication/performace for minimal size.
4) uClibc allows glibc-like custom printf functions.  However, while not
   currently checked, the specifier must be


原文链接：
http://www.ucdot.org/article.pl?sid=02/08/21/1124218&mode=thread
What is the difference between uC-libc and uClibc There are two libc libraries commonly used with uClinux. uC-libc and uClibc. They are quite different despite their similar names. Here is a quick overview of how they are different.
uC-libc is the original library for uClinux. It was based on sources from the Linux-8086 C library which was part of the
ELKs
project with m68000 support added by Jeff Dionne and Kenneth Albanowski. It is a fairly complete libc implementation, however, some of the API's are a little non-standard and quite a few common libc routines are not present. Currently it has stable support for m68000, ColdFire and ARM (Non-MMU) architectures. It was primary design goal is to be small and light weight. It does try to conform to any standards, although its API tries to be compatible with most libcs, it is not always exactly the same.
uClibc is a derivative of uC-libc designed to fix the problems with uC-libc. It makes all the API's standard (correct types, args, etc), fills in many of the missing routines, and has been ported to a lot of architectures. In general it tries to provide glibc compatibility so that porting applications to the smaller uClibc is quite easy. It can be used on standard VM Linux and uClinux. To make it even more compact it can also be compiled as a shared library on most platforms with MMU support
Erik Andersen
has been the driving force behind uClibc and has done a great job. uClibc supports a large array of processors: m68000, Coldfire, ARM, MIPS, v850, x86, i960, Sparc, SuperH, Alpha, PowerPC and Hitachi 8. uClibc is much easier to adapt to a new architecture and its ever growing platform support is testimony to this.
The uClinux distribution provides an environment that can compile using either uC-libc or uClibc depending on your needs. For m68000 and Coldfire platforms it is generally better to chose uC-libc as it supports shared libraries and is the most commonly used libc for these CPUs. uClibc also works quite well with almost all platforms supported by the distribution. Which libc you choose to use will be decided by your requirements.