summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--docs/uclibc.org/FAQ.html190
-rw-r--r--docs/uclibc.org/index.html38
2 files changed, 116 insertions, 112 deletions
diff --git a/docs/uclibc.org/FAQ.html b/docs/uclibc.org/FAQ.html
index 6f362a672..342b59170 100644
--- a/docs/uclibc.org/FAQ.html
+++ b/docs/uclibc.org/FAQ.html
@@ -78,12 +78,15 @@ to the uClibc home page.</a>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- The letter 'u' is short for µ (the greek letter "mu"). µ is commonly used
- as the abbreviation for the word "micro". The capital "C" is short for
- "controller". So you uClibc is simply the microcontroller C library.
- This is because uClibc was originaly created to support uClinux, a port of
- Linux for MMU-less microcontrollers such as the Dragonball, Coldfire, and
- ARM7TDMI. For simplicity, it is pronounced "yew-see-lib-see".
+ For simplicity, uClibc is pronounced "yew-see-lib-see". The letter
+ 'u' is short for µ (the greek letter "mu"). µ is commonly used as
+ the abbreviation for the word "micro". The capital "C" is short
+ for "controller". So uClibc is sortof an abbreviation for "the
+ microcontroller C library". This is partly historical, since
+ uClibc was originally created to support <a href="http://www.uclinux.org">µClinux</a>, a port of Linux
+ for MMU-less microcontrollers such as the Dragonball, Coldfire, and
+ ARM7TDMI. These days, uClibc works just fine with normal Linux
+ system (like on x86, strongArm, and powerpc).
@@ -95,32 +98,34 @@ to the uClibc home page.</a>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- Sure! In fact, this can be very nice during development. By using it on
- your development system, you can be sure that the code you are working on
- will actually run when you deploy it your target system.
-
+ Sure! In fact, this can be very nice during development. By
+ installing uClibc on your development system, you can be sure that
+ the code you are working on will actually run when you deploy it
+ your target system.
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
- Why are you doing this? Whats wrong with glibc?
+ Why are you doing this? What's wrong with glibc?
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- The inital reason, was that glibc does not support MMU-less systems. But
- also because uClibc is so much smaller then the GNU C library. The GNU C
- library has a different set of goals then uClibc. The GNU C library is a
- great piece of software. It complies with just about every standard ever
- created, and runs on just about every operating system as well -- no small
- task! But there is a price to be paid for that. It is quite a large
- library, and keeps getting larger with each release. It does not even
- pretend to target embedded systems. To quote from Ulrich Drepper, the
- maintainer of GNU libc: "...glibc is not the right thing for [an embedded
- OS]. It is designed as a native library (as opposed to embedded). Many
- functions (e.g., printf) contain functionality which is not wanted in
- embedded systems." 24 May 1999
+ Initially, the project began because glibc does not support
+ MMU-less systems. But uClibc is also very useful because it is so
+ much smaller then the GNU C library. The GNU C library is designed
+ with a very different set of goals then uClibc. The GNU C library
+ is a great piece of software, make no mistake. It is compliant to
+ just about every standard ever created, and runs on just about
+ every operating system and architecture -- no small task! But
+ there is a price to be paid for that. It is quite a large library,
+ and keeps getting larger with each release. It does not even
+ pretend to target embedded systems. To quote from Ulrich Drepper,
+ the maintainer of GNU libc: "...glibc is not the right thing for
+ [an embedded OS]. It is designed as a native library (as opposed to
+ embedded). Many functions (e.g., printf) contain functionality
+ which is not wanted in embedded systems." 24 May 1999
@@ -133,20 +138,28 @@ to the uClibc home page.</a>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- uClibc has been designed from the ground up to be a C library for embedded
- Linux. We don't need to worry about whether we support MS-DOS, or Cygwin,
- or any other system. This lets us cut out lots of complexity, and very
- carefully optimize for Linux. By very careful design, we can also take a
- few shortcuts. For example, glibc contains an implementation of the
- wordexp() function, in compliance with the Single Unix Specificaion,
- version 2. Well, standards are important. But so is pragmatism. The
- wordexp function is huge, and yet I am not aware of even one Linux
- application that uses wordexp. So uClibc doesn't provide wordexp(). There
- are many similar examples.
+ uClibc has been designed from the ground up to be a C library for
+ embedded Linux. We don't need to worry about things like MS-DOS
+ support, or Cygwin, or AmigaOs any other system. This lets us cut out
+ a lot of complexity and very carefully optimize for Linux. By very
+ careful design, we can also take a few shortcuts. For example, glibc
+ contains an implementation of the wordexp() function, in compliance
+ with the Single Unix Specification, version 2. Well, standards are
+ important. But so is pragmatism. The wordexp function is huge, yet I
+ am not aware of even one Linux application that uses it! So uClibc
+ doesn't provide wordexp(). There are many similar examples. In other
+ cases, uClibc leaves certain features (such as full C99 Math library
+ support, IPV6, and RPC support) disabled by default. Those features
+ can be enabled for people that need then, but are otherwise disabled to
+ save space.
+
+ <p>
Glibc is a general purpose C library, and so as policy things are optimized
- for speed. Most of uClibc's routines have been very carefuly written to
- optimize them for size instead of speed.
+ for speed. Most of uClibc's routines have been very carefully written to
+ optimize them for size instead.
+
+ <p>
The end result is a C library that will compile just about everything you
throw at it, that looks like glibc to application programs when you
@@ -163,12 +176,11 @@ to the uClibc home page.</a>
<TR><TD BGCOLOR="#eeeee0">
I don't know if you should use uClibc or not. It depends on your needs.
- If you are building an embedded system, and you are tight on space, then
- using uClibc instead if glibc should allow you to use your storage for
- other things.
+ If you are building an embedded Linux system and you are tight on space, then
+ using uClibc instead if glibc may be a very good idea.
- If you are trying to build a ultra fast fileserver for your company that
- has 12 Terabytes of storage, then you probably want to use glibc...
+ 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...
@@ -177,38 +189,28 @@ to the uClibc home page.</a>
<B>
I want to create a closed source commercial application and I want to
protect my intellectual property. If I use uClibc, don't I have to
- release all my source code for free?
+ release all my source code for free? Is that legal?
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
No, you do not need to give away your source code just because you use
- uClibc and/or run on Linux.
+ uClibc and/or run on Linux. uClibc is licensed under the LGPL, just
+ like GNU libc. If you are using uClibc as a shared library, then your
+ closed source application is 100% legal. Please consider sharing some
+ of the money you make with us! :-)
-
-
-<p>
-<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
- <B>
- I want to create a closed source commercial application using uClibc.
- Is that legal?
- </B>
-</TD></TR>
-<TR><TD BGCOLOR="#eeeee0">
-
- Yes. uClibc is licensed under the LGPL, just like GNU libc. If you are
- using uClibc as a shared library, then your closed source application is
- 100% legal. Please consider sharing some of the money you make. :-)
+ <p>
- If you are staticly linking your closed source commercial application with
+ If you are statically linking your closed source application with
uClibc, then you must take additional steps to comply with the uClibc
- license. You can sell your application as usual, but you must also make
- your closed source application available to your customers as an object
- file which can then be linked with updated versions of uClibc. This will
- (in theory) allow your customers to later link with updated versions of
- uClibc. You do not need to make the application object file available to
- everyone, just to those you gave the fully linked application.
-
+ license. You may sell your statically linked application as usual, but
+ you must also make your application available to your customers as an
+ object file which can later be re-linked against updated versions of
+ uClibc. This will (in theory) allow your customers to apply uClibc bug
+ fixes to your application. You do not need to make the application
+ object file available to everyone, just to those you gave the fully
+ linked application.
<p>
@@ -221,8 +223,8 @@ to the uClibc home page.</a>
The easiest way is to use the compiler wrapper built by uClibc. Instead of
using your usual compiler or cross compiler, you can use i386-uclibc-gcc,
- (or whatever is appropriate for your architecture) and it will automagically
- make your program link against uClibc.
+ (or whatever is appropriate for your target architecture) and your
+ applications will auto-magically link against uClibc.
@@ -244,20 +246,21 @@ to the uClibc home page.</a>
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
- When I run 'ldd' to get a list of the library dependancies for a uClibc
- binary, ldd segfaults! Or it runs my application? Anyways, it doesn't
+ When I run 'ldd' to get a list of the library dependencies for a uClibc
+ binary, ldd segfaults! Or it runs my application! Anyways, it doesn't
work! What should I do?
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
Use the ldd that is built by uClibc, not your system's one. When your
- system's ldd looks for the library dependancies, it actually tries to
- _execute_ that program. This works fine -- usually. I doesn't work at all
- when you are cross compiling (thats why ldd segfaults). The ldd program
- created by uClibc is cross platform and doesn't actually try to run the
- target program like your system one does, so it should do the right thing,
- and won't segfault, even when you are cross compiling.
+ system's ldd looks for library dependencies, it actually _runs_ that
+ program. This works fine -- usually. I doesn't work at all when you
+ have been cross compiling (which is why ldd segfaults). The ldd
+ program created by uClibc is cross platform and doesn't even try to run
+ the target program (like your system one does). So use the uClibc one
+ and it will do the right thing, and it won't segfault even when you are
+ cross compiling.
<p>
@@ -268,7 +271,7 @@ to the uClibc home page.</a>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- This history and origin of uClibc is long and twisty.
+ The history and origin of uClibc is long and twisty.
In the beginning, there was <a href="http://www.gnu.org/software/libc/libc.html">GNU libc</a>. Then, libc4
(which later became linux libc 5) forked from GNU libc version 1.07.4, with
additions from 4.4BSD, in order to support Linux. Later, the <a
@@ -281,17 +284,17 @@ to the uClibc home page.</a>
<p>
I had for some time been despairing over the state of C libraries in Linux.
- GNU libc, the standard, is very poorly suited to embedded systems (and it just
- gets bigger with every release). I spent quite a bit of time looking over the
- other Open Source C libraries that I knew of (listed below), and none of them really
+ GNU libc, the standard, is very poorly suited to embedded systems and
+ has been getting bigger with every release. I spent quite a bit of time looking over the
+ available Open Source C libraries that I knew of (listed below), and none of them really
impressed me. I felt there was a real vacancy in the embedded Linux ecology.
The closest library to what I imagined an embedded C library should be was
- uClibc. But that had a lot of problems too -- not the least of which was that,
+ uClibc. But it had a lot of problems too -- not the least of which was that,
traditionally, uClibc had a complete source tree fork in order to support each
- and every new platform, resulting in a big mess of twisty versions, all
+ and every new platform. This resulted in a big mess of twisty versions, all
different. I decided to fix it and the result is what you see here.
My source tree has now become the official uClibc source tree and it now lives
- on cvs.uclinux.org.
+ on cvs.uclinux.org and www.uclibc.org.
<p>
@@ -299,7 +302,7 @@ to the uClibc home page.</a>
href="http://www.uclinux.org/developers/index.html">D. Jeff Dionne</a>), I
ported it to run on x86. I then grafted in the header files from glibc 2.1.3
and cleaned up the resulting breakage. This (plus some additional work) has
- made it almost completely independant of kernel headers, a large departure from
+ made it almost completely independent of kernel headers, a large departure from
its traditional tightly-coupled-to-the-kernel origins. I have written and/or
rewritten a number of things that were missing or broken, and sometimes grafted
in bits of code from the current glibc and libc5. I have also built a proper
@@ -315,17 +318,18 @@ to the uClibc home page.</a>
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
- I need you to add &lt;favorite feature&gt; now! How come you don't answer all my
- questions on the mailing list withing 5 minutes? I demand that you help me <em>Right Now</em>!
+ I demand that you to add &lt;favorite feature&gt; right now! How come
+ you don't answer all my questions on the mailing list instantly? I demand
+ that you help me with all of my problems <em>Right Now</em>!
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- You have not paid us a single cent and yet you still have the product of
- over year and a half of work from Erik and Manuel and lots of other people.
- How dare you treat us that way! We work on uClibc because we find it
- interesting. If you go off flaming us, we will ignore you.
-
+ You have not paid us a single cent and yet you still have the
+ product of nearly two years of work from Erik and Manuel and
+ many other people. We are not your slaves! We work on uClibc
+ because we find it interesting. If you go off flaming us, we will
+ ignore you.
<p>
@@ -342,8 +346,8 @@ to the uClibc home page.</a>
href="mailto:andersen@codepoet.org">Erik Andersen</a> of <a
href="http://codepoet-consulting.com/">CodePoet Consulting</a> to bid
on your project. If Erik is too busy to personally add your feature, there
- are several other active uClibc contributors who may be able to help you out.
- Erik can contact them and ask them about their availability.
+ are several other active uClibc contributors who will almost certainly be able
+ to help you out. Erik can contact them and ask them about their availability.
<p>
@@ -369,8 +373,8 @@ to the uClibc home page.</a>
</center>
<!-- End PayPal Logo -->
- If you prefer to contact us directly for payments (we have a credit card machine so
- you can avoid online payments), hardware donations, support requests, etc., you can
+ If you prefer to contact us directly for payments (Erik has a credit card machine so
+ you can avoid making payments online), hardware donations, support requests, etc., you can
contact <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> here.
<p>
diff --git a/docs/uclibc.org/index.html b/docs/uclibc.org/index.html
index bc9a52933..4d4cc936d 100644
--- a/docs/uclibc.org/index.html
+++ b/docs/uclibc.org/index.html
@@ -37,19 +37,19 @@
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
-<a href="http://uclibc.org">uClibc</a> (aka µClibc/pronounced yew-see-lib-see)
+<a href="http://www.uclibc.org">uClibc</a> (aka µClibc/pronounced yew-see-lib-see)
is a C library for embedded Linux systems. It is much smaller then the
<a href="http://www.gnu.org/software/libc/libc.html">GNU C Library</a>, but
nearly all applications supported by glibc also work perfectly with uClibc.
Porting applications from glibc to uClibc typically involves just recompiling
-the source code. uClibc supports standard Linux systems (such as x86,
+the source code. uClibc supports standard Linux architectures (such as x86,
strongArm, and powerpc), and also supports
-<a href="http://www.uclinux.org">MMU-less (also known as µClinux)</a> systems,
-such as those based on the Coldfire, dragonball, or arm7tdmi micro-controllers.
+<a href="http://www.uclinux.org">MMU-less (also known as µClinux)</a>
+architectures such as the Coldfire, Dragonball, and ARM7TDMI micro-controllers.
If you are building an embedded Linux system and you find that glibc is
-eating up too much space, you should consider using uClibc instead. If you are
-building an ultra fast fileserver with 12 Terabytes of storage, then you probably
-want to use glibc...
+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...
<p>
@@ -74,9 +74,9 @@ to give away all your source code just because you use uClibc and/or run on Linu
<TR><TD BGCOLOR="#eeeee0">
uClibc has a
-<a href="http://uclibc.org/lists/uclibc/">mailing list</a>.
+<a href="http://www.uclibc.org/lists/uclibc/">mailing list</a>.
To subscribe, go and visit
-<a href="http://uclibc.org/mailman/listinfo/uclibc">this page</a>.
+<a href="http://www.uclibc.org/mailman/listinfo/uclibc">this page</a>.
<p>
@@ -91,11 +91,11 @@ To subscribe, go and visit
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- uClibc now has a <a href="http://uclibc.org/uClibc-apps.html">list of applications</a>
+ uClibc now has a <a href="http://www.uclibc.org/uClibc-apps.html">list of applications</a>
that are known to work. Submissions are welcome!
Since most applications work just fine with uClibc, we are especially
interested in knowing about any applications that either do not compile
- or do not work properly with uClibc.
+ at all or do not work properly with uClibc.
@@ -108,7 +108,7 @@ To subscribe, go and visit
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- uClibc now has a <a href="http://uclibc.org/FAQ.html">list of Frequently Asked Questions</a>.
+ uClibc now has a <a href="http://www.uclibc.org/FAQ.html">list of Frequently Asked Questions</a>.
You might want to take a look.
@@ -135,12 +135,12 @@ To subscribe, go and visit
approximately one release per month.
<p>
The source code for this release is available at
- <a href="http://uclibc.org/downloads/">here</a>.
+ <a href="http://www.uclibc.org/downloads/">here</a>.
<p> <li> <b>Old News</b>
<br>
- <a href="http://uclibc.org/old-news.html">Click here to read older news</a>.
+ <a href="http://www.uclibc.org/old-news.html">Click here to read older news</a>.
<p>
@@ -156,10 +156,10 @@ To subscribe, go and visit
<TR><TD BGCOLOR="#eeeee0">
<ul>
<li> There is now a script that creates a daily snapshot tarball of uClibc and posts it on
- <a href="http://uclibc.org/downloads/uClibc-snapshot.tar.gz">here</a>.
- <li> uClibc also has a publically browsable
+ <a href="http://www.uclibc.org/downloads/uClibc-snapshot.tar.gz">here</a>.
+ <li> uClibc also has a publicly browsable
<a href="http://cvs.uclinux.org/cgi-bin/cvsweb/uClibc/">CVS tree</a> (this CVS tree is also mirrored onto
- <a href="http://uclibc.org/cgi-bin/cvsweb/uClibc/">uclibc.org</a> but they are both the same thing).
+ <a href="http://www.uclibc.org/cgi-bin/cvsweb/uClibc/">www.uclibc.org</a> but they are both the same thing).
<li> Anonymous
<a href="http://cvs.uclinux.org/cvs_anon.html">CVS access</a> is available, and
@@ -281,10 +281,10 @@ Here are a few things on the TODO list:
<li> <a href="http://www.uclinux.org/">The uClinux home page</a>
<p>
- <li> <a href="http://cvs.uclinux.org/">The uClinux CVS reporitory</a>
+ <li> <a href="http://cvs.uclinux.org/">The uClinux CVS repository</a>
<p>
- <li> <a href="http://uclibc.org/">The uClibc home page</a>
+ <li> <a href="http://www.uclibc.org/">The uClibc home page</a>
<p>
<li> <a href="http://busybox.net/">BusyBox</a>