diff options
| -rw-r--r-- | README | 52 | ||||
| -rw-r--r-- | docs/uclibc.org/FAQ.html | 14 | ||||
| -rw-r--r-- | docs/uclibc.org/index.html | 13 |
3 files changed, 44 insertions, 35 deletions
@@ -9,33 +9,37 @@ also work perfectly with uClibc. Porting applications from glibc 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 @@ Please Note: 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 diff --git a/docs/uclibc.org/FAQ.html b/docs/uclibc.org/FAQ.html index 53cd52f88..1017e22a0 100644 --- a/docs/uclibc.org/FAQ.html +++ b/docs/uclibc.org/FAQ.html @@ -53,8 +53,8 @@ to the uClibc home page.</a> </TD></TR> <TR><TD BGCOLOR="#eeeee0"> - Currently uClibc runs on alpha, ARM, i386, i960, h8300, m68k, mips/mipsel, - PowerPC, SH, SPARC, and v850 processors. + Currently uClibc runs on alpha, ARM, cris, h8300, i386, i960, m68k, + mips/mipsel, PowerPC, SH, SPARC, and v850 processors. <p> @@ -166,10 +166,12 @@ to the uClibc home page.</a> <p> - If you are trying to build a huge fileserver for your company that will - have 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... + 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 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... diff --git a/docs/uclibc.org/index.html b/docs/uclibc.org/index.html index 6d83c33a6..30b8703bc 100644 --- a/docs/uclibc.org/index.html +++ b/docs/uclibc.org/index.html @@ -47,14 +47,17 @@ uClibc. Porting applications from glibc to uClibc typically involves just recompiling the source code. uClibc even supports shared libraries and threading. It currently runs on <a href="http://kernel.org/">standard Linux</a> and <a href="http://www.uclinux.org">MMU-less (also known as µClinux)</a> -systems with support for alpha, ARM, i386, i960, h8300, m68k, mips/mipsel, +systems with support for alpha, ARM, cris, i386, i960, h8300, m68k, mips/mipsel, PowerPC, SH, SPARC, and v850 processors. <p> -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, than using -glibc may be a better choice... +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 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... + <p> uClibc is maintained by |