summaryrefslogtreecommitdiff
path: root/docs/uclibc.org/FAQ.html
diff options
context:
space:
mode:
authorEric Andersen <andersen@codepoet.org>2002-02-01 11:35:00 +0000
committerEric Andersen <andersen@codepoet.org>2002-02-01 11:35:00 +0000
commit7fa1ecbbee59a40ec35de8f22968ea6cf05a2969 (patch)
treed44eef97a9476d58f0b55d154403b1714ed562bc /docs/uclibc.org/FAQ.html
parent4718635bcc271b6ebc048bab4eb42df8477a57d5 (diff)
Cleanup grammar and wording
Diffstat (limited to 'docs/uclibc.org/FAQ.html')
-rw-r--r--docs/uclibc.org/FAQ.html190
1 files changed, 97 insertions, 93 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>