From 7fa1ecbbee59a40ec35de8f22968ea6cf05a2969 Mon Sep 17 00:00:00 2001 From: Eric Andersen Date: Fri, 1 Feb 2002 11:35:00 +0000 Subject: Cleanup grammar and wording --- docs/uclibc.org/FAQ.html | 190 ++++++++++++++++++++++++----------------------- 1 file changed, 97 insertions(+), 93 deletions(-) (limited to 'docs/uclibc.org/FAQ.html') 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. - 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 µClinux, 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. - 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.

- Why are you doing this? Whats wrong with glibc? + Why are you doing this? What's 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 + 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. - 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. + +

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. + +

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. 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. 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? 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! :-) - - -

- - - 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 + 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.

@@ -221,8 +223,8 @@ to the uClibc home page. 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.

- 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? 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.

@@ -268,7 +271,7 @@ to the uClibc home page. - 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 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

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.

@@ -299,7 +302,7 @@ to the uClibc home page. href="http://www.uclinux.org/developers/index.html">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 + 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.

- 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! + 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 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. - + 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.

@@ -342,8 +346,8 @@ to the uClibc home page. href="mailto:andersen@codepoet.org">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. + 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.

@@ -369,8 +373,8 @@ to the uClibc home page. - 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 CodePoet Consulting here.

-- cgit v1.2.3