oss
/
uclibc-ng


			
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451
							<!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>µ&nbsp;C&nbsp;l&nbsp;i&nbsp;b&nbsp;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, h8300, m68k, mips, 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">

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


<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
    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?  What's wrong with glibc?
    </B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">

    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


<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 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 them, 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 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
    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 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 huge fileserver for your company that will
    have 12 Terabytes of storage, then using glibc may make more sense... 


<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?  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 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>
    
    If you are statically linking your closed source application with
    uClibc, then you must take additional steps to comply with the uClibc
    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>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
    <B>
    How do I compile programs with uClibc?
    </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 target architecture) and your
    applications will auto-magically 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 dependencies for a uClibc
    binary, ldd segfaults!  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 library dependencies, it actually _runs_ that
    program.  This works fine -- usually.  It 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>
<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">

    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
    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
    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 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.  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 and www.uclibc.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 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
    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>

    These days, uClibc is being developed and enhanced by Erik Andersen of
    <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> along
    with the rest of the embedded Linux community.


<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
    <B>
    I demand that you to add &lt;favorite feature&gt; 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 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>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
    <B>
    I need you to add &lt;favorite feature&gt;!  Are the uClibc developers willing to 
    be paid in order to fix bugs or add in &lt;favorite feature&gt;?  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 will almost certainly 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 (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>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
    <B>
	Ok, I'm done reading all these questions.
    </B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">

<a href="http://uclibc.org/">Well then, click here to return to the uClibc home page.</a>


<!-- End things -->

</TD></TR>
</TABLE>
</P>


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