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.
+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
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.
+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
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 be avoided. These days, using ldap is much
+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 and has no actual support for Network Information Service (NIS).
+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. I am open to implementing ldap based password
-authentication, but I do not personally intend to implement it (since I have no
-use for it).
+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.
+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 the kernel types to define most opaque data types.
+12) uClibc directly uses kernel types to define most opaque data types.
-13) uClibc directly uses the linux kernel's arch specific 'stuct stat'.
+13) uClibc directly uses the linux kernel's arch specific 'struct stat'.
-14) Add other things here as they come up......
+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).
+
+<other things as we notice them>
9) The FILEs created by glibc's fmemopen(), open_memstream(), and fopencookie()
are not capable of wide orientation. The corresponding uClibc routines do
not have this limitation.
+10) For scanf, the C99 standard states "The fscanf function returns the value of
+ the macro EOF if an input failure occurs before any conversion." But glibc's
+ scanf does not respect conversions for which assignment was surpressed, even
+ though the standard states that the value is converted but not stored.
glibc bugs that Ulrich Drepper has refused to acknowledge or comment on
( http://sources.redhat.com/ml/libc-alpha/2003-09/ )
and explicit UNDEFINED rules.
More to follow as I think of it...
+
+
+
+
+Profiling:
+-------------------------------------------------------------------
+
+uClibc no longer supports 'gcc -fprofile-arcs -pg' style profiling, which
+causes your application to generate a 'gmon.out' file that can then be analyzed
+by 'gprof'. Not only does this require explicit extra support in uClibc, it
+requires that you rebuild everything with profiling support. There is both a
+size and performance penalty to profiling your applications this way, as well
+as Heisenberg effects, where the act of measuring changes what is measured.
+
+There exist a number of less invasive alternatives that do not require you to
+specially instrument your application, and recompile and relink everything.
+
+The OProfile system-wide profiler is an excellent alternative:
+ http://oprofile.sourceforge.net/
+
+Many people have had good results using the combination of Valgrind
+to generate profiling information and KCachegrind for analysis:
+ http://developer.kde.org/~sewardj/
+ http://kcachegrind.sourceforge.net/
+
+Prospect is another alternative based on OProfile:
+ http://prospect.sourceforge.net/
+
+And the Linux Trace Toolkit (LTT) is also a fine tool:
+ http://www.opersys.com/LTT/
+
+FunctionCheck:
+ http://www710.univ-lyon1.fr/~yperret/fnccheck/
+
OSDN Git Service
