diff options
author | Eric Andersen <andersen@codepoet.org> | 2002-10-18 10:19:07 +0000 |
---|---|---|
committer | Eric Andersen <andersen@codepoet.org> | 2002-10-18 10:19:07 +0000 |
commit | 6bc59b1625c660a7f9391ff085d1073f2b984b63 (patch) | |
tree | 24a951172d743f30ed4547c4419d94a18c56ce50 | |
parent | 08d4be67992784b5dd04e5aaad8248a0dd54b08b (diff) |
Add in an initial list of the differences between glibc and uClibc.
This is not complete, but covers some of the main points.
-Erik
-rw-r--r-- | docs/Glibc_vs_uClibc_Differences.txt | 56 |
1 files changed, 56 insertions, 0 deletions
diff --git a/docs/Glibc_vs_uClibc_Differences.txt b/docs/Glibc_vs_uClibc_Differences.txt new file mode 100644 index 000000000..16608abdf --- /dev/null +++ b/docs/Glibc_vs_uClibc_Differences.txt @@ -0,0 +1,56 @@ +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. + +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. + +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) uClibc does not provide libnsl.so.1, and has no support for Network +Information Service (NIS). + +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. + +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 does not implement wordexp() + + +13) uClibc directly uses the kernel types to define most opaque data types. + +14) uClibc directly uses the linux kernel's arch specific 'stuct stat'. + +15) Add other things here as they come up...... |