Subversion Repositories or1k

<!--#include file="header.html" -->

<h3>Frequently Asked Questions</h3>

This is a collection of some of the most 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,

<ol>

  <li><a href="#naming">Why is it called uClibc?</a>

  <li><a href="#platforms">What platforms does uClibc run on?</a>

  <li><a href="#why">Why are you doing this?  What's wrong with glibc?</a>

  <li><a href="#doesnt_suck">So uClibc is smaller then glibc?  Doesn't that mean it

        completely sucks?  How could it be smaller and not suck?</a>

  <li><a href="#why_should_i">Why should I use uClibc?</a>

  <li><a href="#licensing">If I use uClibc, do I have to release all my source code to the world for

        free?  I want to create a closed source commercial application and I want

        to protect my intellectual property.</a>

  <li><a href="#development">Can I use it on my x86 development system?</a>

  <li><a href="#shared"> Does uClibc support shared libraries?</a>

    <li><a href="#compiling">How do I compile programs with uClibc?</a>

    <li><a href="#dev_systems">Is a pre-compiled uClibc development system available?</a>

    <li><a href="#job_control">Why do I keep getting "sh: can't access tty; job control

            turned off" errors?  Why doesn't Control-C work within my shell?</a>

    <li><a href="#autoconf">How do I make autoconf and automake behave?</a>

    <li><a href="#ldd">When I run 'ldd' to get a list of the library dependencies

            for a uClibc binary, ldd segfaults!  What should I do?</a>

    <li><a href="#timezones">Why does localtime() return times in UTC even when I have my timezone set?</a>

    <li><a href="#history">What is the history of uClibc?  Where did it come from?</a>

    <li><a href="#demanding">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>!</a>

    <li><a href="#contracts">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 <favorite feature>?  Are you willing to provide

            support contracts?</a>

    <li><a href="#support">I think you guys are great and I want to help support your work!</a>

</ol>

<hr />

<p>

<h2><a name="naming">Why is it called uClibc?</a></h2>

<p>

    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 the name uClibc is sortof an abbreviation for "the

    microcontroller C library".  For simplicity, uClibc is pronounced

    "yew-see-lib-see".

    <p>

    The name 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 also works just fine on normal Linux systems

    (such as i386, ARM, and PowerPC), but we couldn't think of a better name.

<hr />

<p>

<h2><a name="platforms">What platforms does uClibc run on?</a></h2>

<p>

    Currently uClibc runs on alpha, ARM, cris, i386, i960, h8300,

    m68k, mips/mipsel, PowerPC, SH, SPARC, and v850 processors.

<hr />

<p>

<h2><a name="why">Why are you doing this?  What's wrong with glibc?</a></h2>

<p>

    Initially, the project began since the GNU C library lacked support for

    MMU-less systems, and because glibc is very large.  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 with 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

<hr />

<p>

<h2><a name="doesnt_suck">So uClibc is smaller then glibc?  Doesn't that mean it completely sucks?

How could it be smaller and not suck?</a></h2>

<p>

<p>

    uClibc and glibc have different goals.  glibc strives for features

    and performance, and is targeted for desktops and servers with

    (these days) lots of resources.  It also strives for ABI stability.

    <p>

    On the other hand, the goal of uClibc is to provide as much functionality

    as possible in a small amount of space, and it is intended primarily for

    embedded use.  It is also highly configurable in supported features, at the

    cost of ABI differences for different configurations.  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 BeOS, or AmigaOs any

    other system.  This lets us cut out a lot of complexity and very carefully

    optimize for Linux.

    <p>

    In other cases, uClibc

    leaves certain features (such as full C99 Math library support, wordexp,

    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>

    Some of the space savings in uClibc is obtained at the cost of performance,

    and some is due to sacrificing features.  Much of it comes from aggressive

    refactoring of code to eliminate redundancy.  In regards to locale data,

    elimination of redundant data storage resulted in substantial space

    savings.  The result is a libc that currently includes the features needed

    by nearly all applications and yet is considerably smaller than glibc.  To

    compare "apples to apples", if you take uClibc and compile in locale data

    for about 170 UTF-8 locales, then uClibc will take up about 570k.  If you

    take glibc and add in locale data for the same 170 UTF-8 locales, you will

    need over 30MB!!!

    <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, and is many times smaller.

<hr />

<p>

<h2><a name="why_should_i">Why should I use uClibc?</a></h2>

<p>

    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.

    <p>

    If you are building an embedded Linux system and you find that

    glibc is eating up too much space, you should consider using

    uClibc.  If you are building a huge fileserver with 12 Terabytes

    of storage, then using glibc may make more sense.  Unless, for

    example, that 12 Terabytes will be Network Attached Storage and

    you plan to burn Linux into the system's firmware...

<hr />

<p>

<h2><a name="licensing">If I use uClibc, do I have to release all my source code to the world for

        free?  I want to create a closed source commercial application and I want

        to protect my intellectual property.</a></h2>

<p>

    No, you do not need to give away your application source code just because

    you use uClibc and/or run on Linux.  uClibc is licensed under the <a

    href="http://www.gnu.org/copyleft/lesser.html">Lesser GPL</a> licence, just

    like the GNU C library (glibc).  Please read this licence, or have a lawyer

    read this licence if you have any questions.  Here is my brief summary...

    Using shared libraries makes complying with the license easy.  You can

    distribute a closed source application which is linked with an unmodified

    uClibc shared library.  In this case, you do not need to give away any

    source code for your application.  Please consider sharing some of the

    money you make with us!  :-)

    <p>

    If you make any changes to uClibc, and distribute uClibc or distribute any

    applications using your modified version, you must also distribute the

    source code for uClibc containing all of your changes.

    <p>

    If you distribute an application which has uClibc statically linked, you

    must also make your application available 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.

<hr />

<p>

<h2><a name="development">Can I use it on my x86 development system?</a></h2>

<p>

    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 on

    your target system.

<hr />

<p>

<h2><a name="shared"> Does uClibc support shared libraries?</a></h2>

<p>

    Yes.  uClibc has native shared library support on i386, ARM, mips,

    SH, CRIS, and PowerPC processors.  Other architectures can use shared

    libraries but will need to use the GNU libc shared library loader.

    <p>

    Shared Libraries are not currently supported by uClibc on MMU-less systems.

    <a href="http://www.snapgear.com/">SnapGear</a> has implemented

    shared library support for MMU-less systems, however, so if you need MMU-less

    shared library support they may be able to help.

<hr />

<p>

<h2><a name="compiling">How do I compile programs with uClibc?</a></h2>

<p>

    You will need to have your own uClibc toolchain (i.e. GNU binutils and

    gcc configured to produce binaries linked with uClibc).

    You can build your own native uClibc toolchain using the uClibc

    toolchain builder from

    <a href="/cgi-bin/cvsweb/toolchain/">uClibc toolchain builder</a>,

    or the uClibc buildroot system from

    <a href="/cgi-bin/cvsweb/buildroot/">uClibc buildroot system</a>.

    Simply adjust the Makefile settings to match your target system,

    and then run 'make'.

<hr />

<p>

<h2><a name="dev_systems">Is a pre-compiled uClibc development system available?</a></h2>

<p>

    If you want to be <em>really</em> lazy and start using uClibc right

    away without needing to compile your own toolchain or anything, you can

    grab a copy of the uClibc development systems, currently available for

    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_i386.bz2">i386</a>,

    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_powerpc.bz2">powerpc</a>,

    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_arm.bz2">arm</a>,

    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_mips.bz2">mips</a>,

    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_mipsel.bz2">mipsel</a>, and

    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_sh4.bz2">sh4</a>.

    The powerpc dev system mostly works, but there is still some sortof

    problem with the shared library loader that has not yet been resolved.

    <p>

    These are pre-built uClibc only development systems (created using

    <a href="/cgi-bin/cvsweb/buildroot/">buildroot</a>), and provide a

    really really easy way to get started.  These are about bzip2 compressed

    ext2 filesystems containing all the development software you need to build

    your own uClibc applications.  With bash, awk, make, gcc, g++, autoconf,

    automake, ncurses, zlib, openssl, openssh, gdb, strace, busybox, GNU

    coreutils, GNU tar, GNU grep, etc, these should have pretty much everything

    you need to get started building your own applications linked against

    uClibc.  You can boot into them, loop mount them, dd them to a spare drive

    and use resize2fs to make them fill a partition...  Whatever works best for

    you.

    <p>

    The quickest way to get started using a root_fs image (using the i386

    platform as an example) is:

    <ul>

    <li>Download root_fs_i386.bz2 from kernel.org</li>

    <li>bunzip2 root_fs_i386.bz2</li>

    <li>mkdir root_fs</li>

    <li>su root</li>

    <li>mount -o loop root_fs_i386 root_fs</li>

    <li>chroot root_fs /bin/sh</li>

    </ul>

    Type "exit" to end the chroot session and return to the host system.

    <p>

<hr />

<p>

<h2><a name="job_control">Why do I keep getting "sh: can't access tty; job control

        turned off" errors?  Why doesn't Control-C work within my shell?</a></h2>

<p>

    This isn't really a uClibc question, but I'll answer it here anyways.  Job

    control will be turned off since your shell can not obtain a controlling

    terminal.  This typically happens when you run your shell on /dev/console.

    The kernel will not provide a controlling terminal on the /dev/console

    device.  Your should run your shell on a normal tty such as tty1 or ttyS0

    and everything will work perfectly.  If you <em>REALLY</em> want your shell

    to run on /dev/console, then you can hack your kernel (if you are into that

    sortof thing) by changing drivers/char/tty_io.c to change the lines where

    it sets "noctty = 1;" to instead set it to "0".  I recommend you instead

    run your shell on a real console...

<hr />

<p>

<h2><a name="autoconf">How do I make autoconf and automake behave?</a></h2>

<p>

    When you are cross-compiling, autoconf and automake are known to behave

    badly.  This is because a large number of configure scripts (such as the

    one from openssh) try to actually execute applications that were cross

    compiled for your target system.  This is bad, since of course these won't

    run, and this will also prevent your programs from compiling.  You need to

    complain to the authors of these programs and ask them to fix their broken

    configure scripts.

<hr />

<p>

<h2><a name="ldd">When I run 'ldd' to get a list of the library dependencies

        for a uClibc binary, ldd segfaults!  What should I do?</a></h2>

<p>

    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 generally will not 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.

<hr />

<p>

<h2><a name="timezones">Why does localtime() return times in UTC even when I have my timezone set?</a></h2>

<p>

    The uClibc time functions get timezone information from the TZ environment

    variable, as described in the Single Unix Specification Version 3.  See

     <a href="http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html">

    http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html</a>

    for details on valid settings of TZ.  For some additional examples, read

    <a href="http://www.uclibc.org/lists/uclibc/2002-August/006261.html">

    http://www.uclibc.org/lists/uclibc/2002-August/006261.html</a> in the uClibc

    mailing list archive.

    You can store the value of TZ in the file '/etc/TZ' and uClibc will then

    automagically use the specified setting.

<hr />

<p>

<h2><a name="history">What is the history of uClibc?  Where did it come from?</a></h2>

<p>

    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, 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 required 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.

    <p>

    To start with, (with some initial help from <a

    href="http://www.uclinux.org/developers/">D. Jeff Dionne</a>), I

    ported uClibc to run on i386.  I then grafted in the header files from glibc

    and cleaned up the resulting breakage.  This (plus some additional work) has

    made it much less dependant on 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 added a proper

    configuration system which allows you to easily select your target architecture

    and enable and disable various features.  Many people have helped by testing,

    contributing ports to new architectures, and adding support for missing features.

    <p>

    In particular, around the end of 2000, Manuel Novoa III got involved with

    uClibc.  One of his first contributions was the original gcc wrapper (which

    has since been removed).  Since then, he has written virtually all of the

    current uClibc stdio, time, string, ctype, locale, and wchar-related code,

    as well as much of stdlib and various other bits throught the library.

    <p>

    These days, uClibc is being developed and enhanced by Erik Andersen

    and Manuel Novoa III of

    <a href="http://codepoet-consulting.com/">CodePoet Consulting</a>

    along with the rest of the embedded Linux community.

<hr />

<p>

<h2><a name="demanding">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>!</a></h2>

<p>

    You have not paid us a single cent and yet you still have the

    product of several 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.

<hr />

<p>

<h2><a name="contracts">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 <favorite feature>?  Are you willing to provide

        support contracts?</a></h2>

<p>

    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.

<hr />

<p>

<h2><a name="support">I think you guys are great and I want to help support your work!</a></h2>

<p>

    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" name="submit" alt="Make donation using PayPal">

    </form>

    </center>

    <!-- End PayPal Logo -->

    If you prefer to contact us directly for payments, hardware donations,

    support requests, etc., you can contact

    <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> here.

<hr />

<!--#include file="footer.html" -->