uClibc FAQ-- a C library for embedded systems

From 3deb1308865cc114984e9396af2ff80daa186a1b Mon Sep 17 00:00:00 2001 From: Eric Andersen Date: Thu, 20 Dec 2001 14:23:44 +0000 Subject: Update the docs and website --- docs/uclibc.org/FAQ.html | 436 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 436 insertions(+) create mode 100644 docs/uclibc.org/FAQ.html (limited to 'docs/uclibc.org/FAQ.html') diff --git a/docs/uclibc.org/FAQ.html b/docs/uclibc.org/FAQ.html new file mode 100644 index 000000000..92b227edb --- /dev/null +++ b/docs/uclibc.org/FAQ.html @@ -0,0 +1,436 @@ + + + + + uClibc FAQ-- a C library for embedded systems + + + + + + + + +

+ + + + + +
+ + µ C l i b c + +
+

+ + + + + + + + + + + + + + + + + + + + + + + + + +
+ + uClibc Frequently Asked Questions (FAQ) + + +
+ +
+This is a collection of some of the frequently asked questions +about uClibc. Some of the questions even have answers. If you +have additions to this FAQ document, we would love to add them, +
+When you are done, you can click here to return +to the uClibc home page. + +
+
+ + What platforms does uClibc run on? + +
+ + Currently uClibc runs on arm, i386, m68k, mipsel, powerpc, sh, + sparc, and v850. + + +
+
+ + 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. + + + +
+
+ + Why is it called uClibc? + +
+ + 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". + + + +
+
+ + 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 when you deploy it your target system. + + + +
+
+ + Why are you doing this? Whats wrong with glibc? + +
+ + 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 + + + +
+
+ + 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 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. + + 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. + + 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 + compile, but is many times smaller. + + + +
+
+ + Why should I use uClibc? + +
+ + 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 trying to build a ultra fast fileserver for your company that + has 12 Terabytes of storage, then you probably want to use glibc... + + + +
+
+ + 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? + +
+ + No, you do not need to give away your source code just because you use + uClibc and/or run on Linux. + + + +
+
+ + 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. + + + +
+
+ + 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. + + + +
+
+ + 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_. + + + +
+
+ + 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. + + +
+
+ + What is the history of uClibc? Where did it come from? + +
+ + This history and origin of uClibc is long and twisty. + In the beginning, there was GNU libc. 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 Linux-8086 C library, which is part of + the elks project, was created, + which was, apparently, largely written from scratch but also borrowed code from + libc4, glibc, some Atari library code, with bits and pieces from about 20 other + places. Then uClibc forked off from the Linux-8086 C library in order to run + on µClinux. +
+ + 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 + 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, + 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 + 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. + +
+ + To start with, (with some initial help from D. Jeff Dionne), 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 + 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 + platform abstraction layer, so now you can simply edit the file "Config" and + use that to decide which architecture you will be compiling for, and whether or + not your target has an MMU, and FPU, etc. I have also added a test suite, + which, though incomplete, is a good start. Several people have helped by + contributing ports to new architectures, and a lot of work has been done on + adding support for missing features. + + + +
+
+ + 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 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. + + + +
+
+ + 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 uClibc contributors who may be able to help you out. + Erik can contact them and ask them about their availability. + + +
+
+ + I think you guys are great and I want to help support your work! + +
+ + Wow, that would be great! You can click here to help support uClibc and/or request features. + + + +
+ + + + + + +
+ + + + 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 + contact CodePoet Consulting here. + +
+
+ + Ok, I'm done reading all these questions. + +
+
+

+ +Well then, click here to return to the uClibc home page. + + + +

+ + + + + + + + + + + + + + + +

+ + Mail all comments, insults, suggestions and bribes to + Erik Andersen
+ +

+ + + + + + + + -- cgit v1.2.3