summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorEric Andersen <andersen@codepoet.org>2002-10-18 10:19:07 +0000
committerEric Andersen <andersen@codepoet.org>2002-10-18 10:19:07 +0000
commit6bc59b1625c660a7f9391ff085d1073f2b984b63 (patch)
tree24a951172d743f30ed4547c4419d94a18c56ce50
parent08d4be67992784b5dd04e5aaad8248a0dd54b08b (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.txt56
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......