I just spent a bit of time writing up a FAQ...

 -Erik

1 files changed, 172 insertions, 0 deletions

diff --git a/FAQ.txt b/FAQ.txt
new file mode 100644
index 000000000..f3a6af570
--- /dev/null
+++ b/FAQ.txt
@@ -0,0 +1,172 @@
+This is a collection of some of the frequently asked question
+about uClibc.  Some of the questions even have answers. If you
+have additions to this FAQ document, I'd love to add them,
+
+ -Erik
+
+
+Q: Why is it called uClibc?
+
+    The letter 'u' is short for the greek letter "mu".  "Mu" stands for
+    "micro", and the "C" is for "controller".  uClibc was originaly created to
+    support uClinux, a port of Linux for MMU-less microcontrollers such as the
+    Dragonball, Coldfire, and ARM7TDMI.  
+
+
+
+Q: Can I use it on my desktop x86 system?
+
+    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 on your target system.
+
+
+
+Q: Why are you doing this?  Whats wrong with glibc?
+
+    The inital reason, is that glibc does not support MMU-les systems.  But
+    additionaly, 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
+
+
+Q: So uClibc is smaller then glibc?  Doesn't that mean it completely sucks?
+    How could it be smaller and not suck?
+
+    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 make a
+    few shotcuts.  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 adds almost 100k to glibc, and yet I am not aware of even
+    one Linux application that uses wordexp.  So uClibc doesn't have wordexp().
+
+    Glibc is a general purpose C library, and so as policy things are optimized
+    for speed.  uClibc has a large number of routines that have been very
+    carefuly written to optimize for size instead of speed.
+
+    The end result is a C library that will compile just about everything you
+    throw at it, thet looks like glibc to application programs when you
+    compile, and is many times smaller.
+
+    
+
+Q: Why should I use uClibc?
+
+    I don't know if you should use uClibc or not.  It depends on your goals.
+    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 trying to build a ultra fast fileserver for your company that
+    has 12 Terabytes of storage, then you probably want to use glibc... 
+
+
+
+
+Q: 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 my source code?
+
+    No, you do not need to give away your source code just because you use
+    uClibc and/or run on Linux.  
+
+
+
+Q: I want to create a closed source commercial application using uClibc.  
+    Is that legal?
+
+    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.  :-)
+    
+    If you are staticly linking your closed source commercial 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.
+
+
+
+Q: How do I compile stuff?
+
+    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.
+
+
+
+Q: How do I make autoconf and automake behave?
+    First run
+	export PATH=/usr/i386-linux-uclibc/bin:$PATH
+    (or similar adjusted for your target architecture) then run you can simply
+    run autoconf/automake and it should _just work_.
+
+
+
+Q: When I run 'ldd' to get a list of the library dependancies for a uClibc
+    binary, ldd segfault!  Or it runs my application?  Anyways, it doesn't 
+    work!  What should I do?
+
+    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.
+
+
+
+Q: I need you to add <favorite feature> now!   How come you don't answer all my
+    questions on the mailing list withing 5 minutes?  I demand that you help me
+    Right Now!
+
+
+    You have not paid me a single cent and yet you still have the product of
+    over year and a half of my work, and lots of work from other people.  How
+    dare you treat me that way!  I work on uClibc because I find it
+    interesting.  If you go off flaming me, I will ignore you.
+    
+
+
+Q: I need you to add <favorite feature>!  Are the uClibc developers willing to 
+    be paid in order to add in <favorite feature>?  Are you willing to provide
+    support contracts?  
+    
+
+    Sure!  Now you have our attention!  What you should do is contact 
+    Erik Andersen of CodePoet Consulting to bid on your project.  If Erik
+    is too busy to personally add your feature
+    
+    
+Q: I think you guys are great and I want to help support your work!
+
+    Wow, that would be great!  You can visit 
+	    http://paypal.com/ 
+    click on "Send Money" and donate to andersen@codepoet.org
+
+
+
+I hope that was helpful...  If you have and comment, corrections, insults,
+suggestions, or bribes, email me at andersen@codepoet.org.
+
+ -Erik
+
+--
+Erik B. Andersen             
+andersen@codepoet.org
+http://codepoet-consulting.com/