|
|
@@ -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>
|
|
|
|
|
|
|
|
|
- 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>
|
Eric Andersen