[uClibc-cvs] uClibc README,1.17,1.18

Erik Andersen andersen at uclibc.org
Tue Sep 9 10:02:33 UTC 2003


Update of /var/cvs/uClibc
In directory winder:/tmp/cvs-serv31560

Modified Files:
	README 
Log Message:
Yet more trivial doc updates


Index: README
===================================================================
RCS file: /var/cvs/uClibc/README,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -d -r1.17 -r1.18
--- README	12 Feb 2003 13:15:03 -0000	1.17
+++ README	9 Sep 2003 10:02:29 -0000	1.18
@@ -9,33 +9,37 @@
 to uClibc typically involves just recompiling the source code.
 uClibc even supports shared libraries and threading. It currently
 runs on standard Linux and MMU-less (also known as µClinux)
-systems with support for alpha, ARM, i386, i960, h8300, m68k,
-mips/mipsel, PowerPC, SH, SPARC, and v850 processors.
+systems with support for alpha, ARM, cris, h8300, i386, i960,
+m68k, mips/mipsel, PowerPC, SH, SPARC, and v850 processors.
 
 If you are building an embedded Linux system and you find that
 glibc is eating up too much space, you should consider using
-uClibc. If you are building a huge fileserver with 12 Terabytes
-of storage, then using glibc may be a better choice...
+uClibc.  If you are building a huge fileserver with 12 Terabytes
+of storage, then using glibc may make more sense.  Unless, for
+example, that 12 Terabytes will be Network Attached Storage and
+you plan to burn Linux into the system's firmware...
 
 uClibc is maintained by Erik Andersen and is licensed under the
 GNU LIBRARY GENERAL PUBLIC LICENSE . This license allows you to
-make closed source commercial applications using uClibc (Please
-consider sharing some of the money you make ;-). You do not need
-to give away all your source code just because you use uClibc
-and/or run on Linux. 
+make closed source commercial applications using an unmodified
+version of uClibc (Please consider sharing some of the money you
+make ;-). You do not need to give away all your source code just
+because you use uClibc and/or run on Linux. 
 
 
 For installation instructions, see the file INSTALL.
 
-This distribution contains a wrapper for gcc and ld that allows you
-to use existing toolchains that were targetted for glibc.  See
-extra/gcc-uClibc/ for information.
+This distribution contains a wrapper for gcc and ld that allows
+you to use existing toolchains that were targetted for glibc.
+There are limits as to what this wrapper can do, so it is
+recommended that you instead build a full binutils/gcc toolchain.
 
 uClibc strives to be standards compliant, which means that most
-documentation written for functions in glibc also applies to uClibc
-functions.  However, many GNU extensions are not supported because
-they have not been ported, or more importantly, would increase the
-size of uClibc disproportional to the added functionality.
+documentation written for SuSv3, or for glibc also applies to
+uClibc functions.  However, many GNU extensions are not supported
+because they have not been ported, or more importantly, would
+increase the size of uClibc disproportional to the added
+functionality.
 
 Additional information (recent releases, FAQ, mailing list, bugs,
 etc.) can be found at http://www.uclibc.org/.
@@ -48,13 +52,13 @@
 
 	There is an unwholesomely huge amount of code out there
 	that depends on the presence of GNU libc header files.
-	We have GNU libc header files.  So we have committed a
-	horrible sin in uClibc.  We _lie_ and claim to be GNU
-	libc in order to force these applications to work as their
-	developers intended.  This is IMHO, pardonable, since
-	these defines are not really intended to check for the
-	presence of a particular library, but rather are used to
-	define an _interface_.  Some programs are especially 
-	chummy with glibc, and may need this behavior disabled 
-	by adding CFLAGS+=-D__FORCE_NOGLIBC
+	We have GNU libc compatible header files.  So we have
+	committed a horrible sin in uClibc.  We _lie_ and claim
+	to be GNU libc in order to force these applications to
+	work as their developers intended.  This is IMHO,
+	pardonable, since these defines are not really intended
+	to check for the presence of a particular library, but
+	rather are used to define an _interface_.  Some programs
+	are especially chummy with glibc, and may need this
+	behavior disabled by adding CFLAGS+=-D__FORCE_NOGLIBC
 




More information about the uClibc-cvs mailing list