docs/Glibc_vs_uClibc_Differences.txt

   1  uClibc and Glibc are not the same -- there are a number of differences which
   2 may or may not cause you problems.  This document attempts to list these
   3 differences and, when completed, will contain a full list of all relevant
   4 differences.
   5
   6
   7 1) uClibc is smaller than glibc.  We attempt to maintain a glibc compatible
   8 interface, allowing applications that compile with glibc to easily compile with
   9 uClibc.  However, we do not include _everything_ that glibc includes, and
  10 therefore some applications may not compile.  If this happens to you, please
  11 report the failure to the uclibc mailing list, with detailed error messages.
  12
  13 2) uClibc is much more configurable then glibc.  This means that a developer
  14 may have compiled uClibc in such a way that significant amounts of
  15 functionality have been omitted.
  16
  17 3) uClibc does not even attempt to ensure binary compatibility across releases.
  18 When a new version of uClibc is released, you may or may not need to recompile
  19 all your binaries.
  20
  21 4) malloc(0) in glibc returns a valid pointer to something(!?!?) while in
  22 uClibc calling malloc(0) returns a NULL.  The behavior of malloc(0) is listed
  23 as implementation-defined by SuSv3, so both libraries are equally correct.
  24 This difference also applies to realloc(NULL, 0).  I personally feel glibc's
  25 behavior is not particularly safe.  To enable glibc behavior, one has to
  26 explicitly enable the MALLOC_GLIBC_COMPAT option.
  27
  28 4.1) glibc's malloc() implementation has behavior that is tunable via the
  29 MALLOC_CHECK_ environment variable.  This is primarily used to provide extra
  30 malloc debugging features.  These extended malloc debugging features are not
  31 available within uClibc.  There are many good malloc debugging libraries
  32 available for Linux (dmalloc, electric fence, valgrind, etc) that work much
  33 better than the glibc extended malloc debugging.  So our omitting this
  34 functionality from uClibc is not a great loss.
  35
  36 5) uClibc does not provide a database library (libdb).
  37
  38 6) uClibc does not support NSS (/lib/libnss_*), which allows glibc to easily
  39 support various methods of authentication and DNS resolution.  uClibc only
  40 supports flat password files and shadow password files for storing
  41 authentication information.  If you need something more complex than this,
  42 you can compile and install pam.
  43
  44 7) uClibc's libresolv is only a stub.  Some, but not all of the functionality
  45 provided by glibc's libresolv is provided internal to uClibc.  Other functions
  46 are not at all implemented.
  47
  48 8) libnsl provides support for Network Information Service (NIS) which was
  49 originally called "Yellow Pages" or "YP", which is an extension of RPC invented
  50 by Sun to share Unix password files over the network.  I personally think NIS
  51 is an evil abomination and should not be used.  These days, using ldap is much
  52 more effective mechanism for doing the same thing.  uClibc provides a stub
  53 libnsl, but has no actual support for Network Information Service (NIS).
  54 We therefore, also do not provide any of the headers files provided by glibc
  55 under /usr/include/rpcsvc.
  56
  57 9) uClibc's locale support is not 100% complete yet.  We are working on it.
  58
  59 10) uClibc's math library only supports long double as inlines, and even
  60 then the long double support is quite limited.  Also, very few of the
  61 float math functions are implemented.  Stick with double and you should
  62 be just fine.
  63
  64 11) uClibc's libcrypt does not support the reentrant crypt_r, setkey_r and
  65 encrypt_r, since these are not required by SuSv3.
  66
  67 12) uClibc directly uses kernel types to define most opaque data types.
  68
  69 13) uClibc directly uses the linux kernel's arch specific 'struct stat'.
  70
  71 14) uClibc's librt library currently lacks all aio routines, all clock
  72     routines, and all shm routines (only the timer routines and the mq
  73     routines are implemented).
  74
  75 <other things as we notice them>
  76
  77
  78
  79 ******************************  Manuel's Notes  ******************************
  80
  81 Some general comments...
  82
  83 The intended target for all my uClibc code is ANSI/ISO C99 and SUSv3
  84 compliance.  While some glibc extensions are present, many will eventually
  85 be configurable.  Also, even when present, the glibc-like extensions may
  86 differ slightly or be more restrictive than the native glibc counterparts.
  87 They are primarily meant to be porting _aides_ and not necessarily
  88 drop-in replacements.
  89
  90 Now for some details...
  91
  92 time functions
  93 --------------
  94 1) Leap seconds are not supported.
  95 2) /etc/timezone and the whole zoneinfo directory tree are not supported.
  96    To set the timezone, set the TZ environment variable as specified in
  97    http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html
  98    or you may also create an /etc/TZ file of a single line, ending with a
  99    newline, containing the TZ setting.  For example
 100    echo CST6CDT > /etc/TZ
 101 3) Currently, locale specific eras and alternate digits are not supported.
 102    They are on my TODO list.
 103
 104 wide char support
 105 -----------------
 106 1) The only multibyte encoding currently supported is UTF-8.  The various
 107    ISO-8859-* encodings are (optionally) supported.  The internal
 108    representation of wchar's is assumed to be 31 bit unicode values in
 109    native endian representation.  Also, the underlying char encoding is
 110    assumed to match ASCII in the range 0-0x7f.
 111 2) In the next iteration of locale support, I plan to add support for
 112    (at least some) other multibyte encodings.
 113
 114 locale support
 115 --------------
 116 1) The target for support is SUSv3 locale functionality.  While nl_langinfo
 117    has been extended, similar to glibc, it only returns values for related
 118    locale entries.
 119 2) Currently, all SUSv3 libc locale functionality should be implemented
 120    except for wcsftime and collating item support in regex.
 121
 122 stdio
 123 -----
 124 1) Conversion of large magnitude floating-point values by printf suffers a loss
 125    of precision due to the algorithm used.
 126 2) uClibc's printf is much stricter than glibcs, especially regarding positional
 127    args.  The entire format string is parsed first and an error is returned if
 128    a problem is detected.  In locales other than C, the format string is checked
 129    to be a valid multibyte sequence as well.  Also, currently at most 10 positional
 130    args are allowed (although this is configurable).
 131 3) BUFSIZ is configurable, but no attempt is made at automatic tuning of internal
 132    buffer sizes for stdio streams.  In fact, the stdio code in general sacrifices
 133    sophistication/performace for minimal size.
 134 4) uClibc allows glibc-like custom printf functions.  However, while not
 135    currently checked, the specifier must be <= 0x7f.
 136 5) uClibc allows glibc-like custom streams.  However, no in-buffer seeking is
 137    done.
 138 6) The functions fcloseall() and __fpending() can behave differently than their
 139    glibc counterparts.
 140 7) uClibc's setvbuf is more restrictive about when it can be called than glibc's
 141    is.  The standards specify that setvbuf must occur before any other operations
 142    take place on the stream.
 143 8) Right now, %m is not handled properly by printf when the format uses positional
 144    args.
 145 9) The FILEs created by glibc's fmemopen(), open_memstream(), and fopencookie()
 146    are not capable of wide orientation.  The corresponding uClibc routines do
 147    not have this limitation.
 148 10) For scanf, the C99 standard states "The fscanf function returns the value of
 149     the macro EOF if an input failure occurs before any conversion."  But glibc's
 150     scanf does not respect conversions for which assignment was surpressed, even
 151     though the standard states that the value is converted but not stored.
 152
 153 glibc bugs that Ulrich Drepper has refused to acknowledge or comment on
 154   ( http://sources.redhat.com/ml/libc-alpha/2003-09/ )
 155 -----------------------------------------------------------------------
 156 1) The C99 standard says that for printf, a %s conversion makes no special
 157    provisions for multibyte characters.  SUSv3 is even more clear, stating
 158    that bytes are written and a specified precision is in bytes.  Yet glibc
 159    treats the arg as a multibyte string when a precision is specified and
 160    not otherwise.
 161 2) Both C99 and C89 state that the %c conversion for scanf reads the exact
 162    number of bytes specified by the optional field width (or 1 if not specified).
 163    uClibc complies with the standard.  There is an argument that perhaps the
 164    specified width should be treated as an upper bound, based on some historical
 165    use.  However, such behavior should be mentioned in the Conformance document.
 166 3) glibc's scanf is broken regarding some numeric patterns.  Some invalid
 167    strings are accepted as valid ("0x.p", "1e", digit grouped strings).
 168    In spite of my posting examples clearly illustrating the bugs, they remain
 169    unacknowledged by the glibc developers.
 170 4) glibc's scanf seems to require a 'p' exponent for hexadecimal float strings.
 171    According to the standard, this is optional.
 172 5) C99 requires that once an EOF is encountered, the stream should be treated
 173    as if at end-of-file even if more data becomes available.  Further reading
 174    can be attempted by clearing the EOF flag though, via clearerr() or a file
 175    positioning function.  For details concerning the original change, see
 176    Defect Report #141.  glibc is currently non-compliant, and the developers
 177    did not comment when I asked for their official position on this issue.
 178 6) glibc's collation routines and/or localedef are broken regarding implicit
 179    and explicit UNDEFINED rules.
 180
 181 More to follow as I think of it...
 182
 183
 184
 185
 186 Profiling:
 187 -------------------------------------------------------------------
 188
 189 uClibc no longer supports 'gcc -fprofile-arcs  -pg' style profiling, which
 190 causes your application to generate a 'gmon.out' file that can then be analyzed
 191 by 'gprof'.  Not only does this require explicit extra support in uClibc, it
 192 requires that you rebuild everything with profiling support.  There is both a
 193 size and performance penalty to profiling your applications this way, as well
 194 as Heisenberg effects, where the act of measuring changes what is measured.
 195
 196 There exist a number of less invasive alternatives that do not require you to
 197 specially instrument your application, and recompile and relink everything.
 198
 199 The OProfile system-wide profiler is an excellent alternative:
 200       http://oprofile.sourceforge.net/
 201
 202 Many people have had good results using the combination of Valgrind
 203 to generate profiling information and KCachegrind for analysis:
 204       http://developer.kde.org/~sewardj/
 205       http://kcachegrind.sourceforge.net/
 206
 207 Prospect is another alternative based on OProfile:
 208       http://prospect.sourceforge.net/
 209
 210 And the Linux Trace Toolkit (LTT) is also a fine tool:
 211     http://www.opersys.com/LTT/
 212
 213 FunctionCheck:
 214         http://www710.univ-lyon1.fr/~yperret/fnccheck/
 215