diff options
Diffstat (limited to 'docs/FAQ.txt')
| -rw-r--r-- | docs/FAQ.txt | 186 |
1 files changed, 186 insertions, 0 deletions
diff --git a/docs/FAQ.txt b/docs/FAQ.txt new file mode 100644 index 000000000..87322174c --- /dev/null +++ b/docs/FAQ.txt @@ -0,0 +1,186 @@ +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: What platforms does uClibc run on? + + Currently uClibc runs on arm, i386, m68k, mipsel, powerpc, sh, + sparc, and v850. + + + +Q: Does uClibc support shared libraries? + + Yes. uClibc has shared library support on x86, arm, and powerpc. + Shared Libraries are _not_ currently supported on MMU-less systems. + + + +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, there are several other + active contributors who may be able to help you out. + + +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/ |