|
@@ -0,0 +1,436 @@
|
|
|
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
|
|
|
+
|
|
|
+<HTML>
|
|
|
+<HEAD>
|
|
|
+ <TITLE>uClibc FAQ-- a C library for embedded systems</TITLE>
|
|
|
+</HEAD>
|
|
|
+
|
|
|
+<body text="#000000" alink="#660000" link="#660000" bgcolor="#dee2de" vlink="#660000">
|
|
|
+
|
|
|
+<basefont face="lucida, helvetica, arial" size="3">
|
|
|
+
|
|
|
+
|
|
|
+<CENTER>
|
|
|
+<p>
|
|
|
+
|
|
|
+<TABLE BORDER=0 CELLSPACING=1 CELLPADDING=2>
|
|
|
+ <TR>
|
|
|
+ <td bgcolor="#000000">
|
|
|
+ <FONT FACE="lucida, helvetica" COLOR="#ccccc0">
|
|
|
+ <B>µ C l i b c</B>
|
|
|
+ </FONT>
|
|
|
+ </TD>
|
|
|
+ </TR>
|
|
|
+</TABLE>
|
|
|
+<p>
|
|
|
+
|
|
|
+
|
|
|
+<!-- Begin NOT Working List -->
|
|
|
+
|
|
|
+
|
|
|
+<TABLE WIDTH=95% CELLSPACING=1 CELLPADDING=4 BORDER=1>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=center>
|
|
|
+ <A NAME="notworking"> <BIG><B>
|
|
|
+ uClibc Frequently Asked Questions (FAQ)
|
|
|
+ </font>
|
|
|
+ </A></B></BIG>
|
|
|
+</TD></TR>
|
|
|
+<TR><TD BGCOLOR="#eeeee0">
|
|
|
+
|
|
|
+<p>
|
|
|
+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,
|
|
|
+<br>
|
|
|
+When you are done, <a href="http://uclibc.org/">you can click here to return
|
|
|
+to the uClibc home page.</a>
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ What platforms does uClibc run on?
|
|
|
+ </B>
|
|
|
+</TD></TR>
|
|
|
+<TR><TD BGCOLOR="#eeeee0">
|
|
|
+
|
|
|
+ Currently uClibc runs on arm, i386, m68k, mipsel, powerpc, sh,
|
|
|
+ sparc, and v850.
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ Does uClibc support shared libraries?
|
|
|
+ </B>
|
|
|
+</TD></TR>
|
|
|
+<TR><TD BGCOLOR="#eeeee0">
|
|
|
+
|
|
|
+ Yes. uClibc has shared library support on x86, arm, and powerpc.
|
|
|
+ Shared Libraries are _not_ currently supported on MMU-less systems.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ Why is it called uClibc?
|
|
|
+ </B>
|
|
|
+</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".
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ Can I use it on my desktop x86 system?
|
|
|
+ </B>
|
|
|
+</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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ Why are you doing this? Whats 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
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ So uClibc is smaller then glibc? Doesn't that mean it completely sucks?
|
|
|
+ How could it be smaller and not suck?
|
|
|
+ </B>
|
|
|
+</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.
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ Why should I use uClibc?
|
|
|
+ </B>
|
|
|
+</TD></TR>
|
|
|
+<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 trying to build a ultra fast fileserver for your company that
|
|
|
+ has 12 Terabytes of storage, then you probably want to use glibc...
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <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?
|
|
|
+ </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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<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. :-)
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ How do I compile stuff?
|
|
|
+ </B>
|
|
|
+</TD></TR>
|
|
|
+<TR><TD BGCOLOR="#eeeee0">
|
|
|
+
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ How do I make autoconf and automake behave?
|
|
|
+ </B>
|
|
|
+</TD></TR>
|
|
|
+<TR><TD BGCOLOR="#eeeee0">
|
|
|
+
|
|
|
+ First run
|
|
|
+ <pre>export PATH=/usr/i386-linux-uclibc/bin:$PATH</pre>
|
|
|
+ (or similar adjusted for your target architecture) then run you can simply
|
|
|
+ run autoconf/automake and it should _just work_.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<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 segfault! 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.
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ What is the history of uClibc? Where did it come from?
|
|
|
+ </B>
|
|
|
+</TD></TR>
|
|
|
+<TR><TD BGCOLOR="#eeeee0">
|
|
|
+
|
|
|
+ This 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
|
|
|
+ href="http://www.cix.co.uk/~mayday/">Linux-8086 C library</a>, which is part of
|
|
|
+ the <a href="http://www.elks.ecs.soton.ac.uk/">elks project</a>, 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 <a href="http://www.uclinux.org">µClinux</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
|
|
|
+ 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.
|
|
|
+
|
|
|
+ <p>
|
|
|
+
|
|
|
+ To start with, (with some initial help from <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
|
|
|
+ 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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<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>!
|
|
|
+ </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.
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ 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?
|
|
|
+ </B>
|
|
|
+</TD></TR>
|
|
|
+<TR><TD BGCOLOR="#eeeee0">
|
|
|
+
|
|
|
+ Sure! Now you have our attention! What you should do is contact <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.
|
|
|
+
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ I think you guys are great and I want to help support your work!
|
|
|
+ </B>
|
|
|
+</TD></TR>
|
|
|
+<TR><TD BGCOLOR="#eeeee0">
|
|
|
+
|
|
|
+ Wow, that would be great! You can click here to help support uClibc and/or request features.
|
|
|
+
|
|
|
+ <!-- Begin PayPal Logo -->
|
|
|
+ <center>
|
|
|
+ <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
|
|
|
+ <input type="hidden" name="cmd" value="_xclick">
|
|
|
+ <input type="hidden" name="business" value="andersen@codepoet.org">
|
|
|
+ <input type="hidden" name="item_name" value="Support uClibc and/or request features">
|
|
|
+ <input type="hidden" name="image_url" value="https://codepoet-consulting.com/images/codepoet.png">
|
|
|
+ <input type="hidden" name="no_shipping" value="1">
|
|
|
+ <input type="image" src="images/donate.png" border="0" name="submit" alt="Make donation using PayPal">
|
|
|
+ </form>
|
|
|
+ </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
|
|
|
+ contact <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> here.
|
|
|
+
|
|
|
+<p>
|
|
|
+<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
|
|
|
+ <B>
|
|
|
+ Ok, I'm done reading all these questions.
|
|
|
+ </B>
|
|
|
+</TD></TR>
|
|
|
+<TR><TD BGCOLOR="#eeeee0">
|
|
|
+</TD></TR>
|
|
|
+</TABLE>
|
|
|
+</P>
|
|
|
+
|
|
|
+<a href="http://uclibc.org/">Well then, click here to return to the uClibc home page.</a>
|
|
|
+
|
|
|
+
|
|
|
+<!-- Footer -->
|
|
|
+<HR>
|
|
|
+<TABLE WIDTH="100%">
|
|
|
+ <TR>
|
|
|
+ <TD>
|
|
|
+ <font size="-1" face="arial, helvetica, sans-serif">
|
|
|
+ Mail all comments, insults, suggestions and bribes to
|
|
|
+ <a href="mailto:andersen@codepoet.org">Erik Andersen</a><BR>
|
|
|
+ </font>
|
|
|
+ </TD>
|
|
|
+
|
|
|
+ <TD>
|
|
|
+ <a href="http://www.vim.org"><img border=0 width=90 height=36
|
|
|
+ src="images/written.in.vi.png"
|
|
|
+ alt="This site created with the vi editor"></a>
|
|
|
+ </TD>
|
|
|
+
|
|
|
+ <TD>
|
|
|
+ <a href="http://www.gimp.org/"><img border=0 width=90 height=36
|
|
|
+ src="images/gfx_by_gimp.png" alt="Graphics by GIMP"></a>
|
|
|
+ </TD>
|
|
|
+
|
|
|
+ <TD>
|
|
|
+ <a href="http://www.linuxtoday.com"><img width=90 height=36
|
|
|
+ src="images/ltbutton2.png" alt="Linux Today"></a>
|
|
|
+ </TD>
|
|
|
+
|
|
|
+ <TD>
|
|
|
+ <p><a href="http://slashdot.org"><img width=90 height=36
|
|
|
+ src="images/sdsmall.png" alt="Slashdot"></a>
|
|
|
+ </TD>
|
|
|
+
|
|
|
+ <TD>
|
|
|
+ <a href="http://freshmeat.net"><img width=90 height=36
|
|
|
+ src="images/fm.mini.png" alt="Freshmeat"></a>
|
|
|
+ </TD>
|
|
|
+
|
|
|
+ </TR>
|
|
|
+</TABLE>
|
|
|
+
|
|
|
+
|
|
|
+</CENTER>
|
|
|
+</BODY>
|
|
|
+</HTML>
|
|
|
+
|
|
|
+
|
|
|
+
|