diff options
Diffstat (limited to 'docs/uclibc.org/FAQ.html')
| -rw-r--r-- | docs/uclibc.org/FAQ.html | 190 |
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 <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 <em>Right Now</em>! + I demand that you to add <favorite feature> 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> |