1 uClibc and Glibc are not the same -- there are a number of differences which 2may or may not cause you problems. This document attempts to list these 3differences and, when completed, will contain a full list of all relevant 4differences. 5 6 71) uClibc is smaller than glibc. We attempt to maintain a glibc compatible 8interface, allowing applications that compile with glibc to easily compile with 9uClibc. However, we do not include _everything_ that glibc includes, and 10therefore some applications may not compile. If this happens to you, please 11report the failure to the uclibc mailing list, with detailed error messages. 12 132) uClibc is much more configurable then glibc. This means that a developer 14may have compiled uClibc in such a way that significant amounts of 15functionality have been omitted. 16 173) uClibc does not even attempt to ensure binary compatibility across releases. 18When a new version of uClibc is released, you may or may not need to recompile 19all your binaries. 20 214) malloc(0) in glibc returns a valid pointer to something(!?!?) while in 22uClibc calling malloc(0) returns a NULL. The behavior of malloc(0) is listed 23as implementation-defined by SuSv3, so both libraries are equally correct. 24This difference also applies to realloc(NULL, 0). I personally feel glibc's 25behavior is not particularly safe. To enable glibc behavior, one has to 26explicitly enable the MALLOC_GLIBC_COMPAT option. 27 284.1) glibc's malloc() implementation has behavior that is tunable via the 29MALLOC_CHECK_ environment variable. This is primarily used to provide extra 30malloc debugging features. These extended malloc debugging features are not 31available within uClibc. There are many good malloc debugging libraries 32available for Linux (dmalloc, electric fence, valgrind, etc) that work much 33better than the glibc extended malloc debugging. So our omitting this 34functionality from uClibc is not a great loss. 35 365) uClibc does not provide a database library (libdb). 37 386) uClibc does not support NSS (/lib/libnss_*), which allows glibc to easily 39support various methods of authentication and DNS resolution. uClibc only 40supports flat password files and shadow password files for storing 41authentication information. If you need something more complex than this, 42you can compile and install pam. 43 447) uClibc's libresolv is only a stub. Some, but not all of the functionality 45provided by glibc's libresolv is provided internal to uClibc. Other functions 46are not at all implemented. 47 488) libnsl provides support for Network Information Service (NIS) which was 49originally called "Yellow Pages" or "YP", which is an extension of RPC invented 50by Sun to share Unix password files over the network. I personally think NIS 51is an evil abomination and should not be used. These days, using ldap is much 52more effective mechanism for doing the same thing. uClibc provides a stub 53libnsl, but has no actual support for Network Information Service (NIS). 54We therefore, also do not provide any of the headers files provided by glibc 55under /usr/include/rpcsvc. 56 579) uClibc's locale support is not 100% complete yet. We are working on it. 58 5910) uClibc's math library only supports long double as inlines, and even 60then the long double support is quite limited. Also, very few of the 61float math functions are implemented. Stick with double and you should 62be just fine. 63 6411) uClibc's libcrypt does not support the reentrant crypt_r, setkey_r and 65encrypt_r, since these are not required by SuSv3. 66 6712) uClibc directly uses kernel types to define most opaque data types. 68 6913) uClibc directly uses the linux kernel's arch specific 'struct stat'. 70 7114) 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 81Some general comments... 82 83The intended target for all my uClibc code is ANSI/ISO C99 and SUSv3 84compliance. While some glibc extensions are present, many will eventually 85be configurable. Also, even when present, the glibc-like extensions may 86differ slightly or be more restrictive than the native glibc counterparts. 87They are primarily meant to be porting _aides_ and not necessarily 88drop-in replacements. 89 90Now for some details... 91 92time functions 93-------------- 941) Leap seconds are not supported. 952) /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 1013) Currently, locale specific eras and alternate digits are not supported. 102 They are on my TODO list. 103 104wide char support 105----------------- 1061) 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. 1112) In the next iteration of locale support, I plan to add support for 112 (at least some) other multibyte encodings. 113 114locale support 115-------------- 1161) 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. 1192) Currently, all SUSv3 libc locale functionality should be implemented 120 except for wcsftime and collating item support in regex. 121 122stdio 123----- 1241) Conversion of large magnitude floating-point values by printf suffers a loss 125 of precision due to the algorithm used. 1262) 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). 1313) 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. 1344) uClibc allows glibc-like custom printf functions. However, while not 135 currently checked, the specifier must be <= 0x7f. 1365) uClibc allows glibc-like custom streams. However, no in-buffer seeking is 137 done. 1386) The functions fcloseall() and __fpending() can behave differently than their 139 glibc counterparts. 1407) 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. 1438) Right now, %m is not handled properly by printf when the format uses positional 144 args. 1459) 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. 14810) 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 153glibc bugs that Ulrich Drepper has refused to acknowledge or comment on 154 ( http://sources.redhat.com/ml/libc-alpha/2003-09/ ) 155----------------------------------------------------------------------- 1561) 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. 1612) 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. 1663) 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. 1704) glibc's scanf seems to require a 'p' exponent for hexadecimal float strings. 171 According to the standard, this is optional. 1725) 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. 1786) glibc's collation routines and/or localedef are broken regarding implicit 179 and explicit UNDEFINED rules. 180 181More to follow as I think of it... 182 183 184 185 186Profiling: 187------------------------------------------------------------------- 188 189uClibc no longer supports 'gcc -fprofile-arcs -pg' style profiling, which 190causes your application to generate a 'gmon.out' file that can then be analyzed 191by 'gprof'. Not only does this require explicit extra support in uClibc, it 192requires that you rebuild everything with profiling support. There is both a 193size and performance penalty to profiling your applications this way, as well 194as Heisenberg effects, where the act of measuring changes what is measured. 195 196There exist a number of less invasive alternatives that do not require you to 197specially instrument your application, and recompile and relink everything. 198 199The OProfile system-wide profiler is an excellent alternative: 200 http://oprofile.sourceforge.net/ 201 202Many people have had good results using the combination of Valgrind 203to generate profiling information and KCachegrind for analysis: 204 http://developer.kde.org/~sewardj/ 205 http://kcachegrind.sourceforge.net/ 206 207Prospect is another alternative based on OProfile: 208 http://prospect.sourceforge.net/ 209 210And the Linux Trace Toolkit (LTT) is also a fine tool: 211 http://www.opersys.com/LTT/ 212 213FunctionCheck: 214 http://www710.univ-lyon1.fr/~yperret/fnccheck/ 215 216