docs/uclibc.org/FAQ.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
   2
   3 <HTML>
   4 <HEAD>
   5     <TITLE>uClibc FAQ-- a C library for embedded systems</TITLE>
   6 </HEAD>
   7
   8 <body text="#000000" alink="#660000" link="#660000" bgcolor="#dee2de" vlink="#660000">
   9
  10 <basefont face="lucida, helvetica, arial" size="3">
  11
  12
  13 <CENTER>
  14 <p>
  15
  16 <TABLE BORDER=0 CELLSPACING=1 CELLPADDING=2>
  17     <TR>
  18         <td bgcolor="#000000">
  19           <FONT FACE="lucida, helvetica" COLOR="#ccccc0">
  20               <B>µ&nbsp;C&nbsp;l&nbsp;i&nbsp;b&nbsp;c</B>
  21           </FONT>
  22         </TD>
  23     </TR>
  24 </TABLE>
  25 <p>
  26
  27
  28 <!-- Begin NOT Working List -->
  29
  30
  31 <TABLE WIDTH=95% CELLSPACING=1 CELLPADDING=4 BORDER=1>
  32 <TR><TD BGCOLOR="#ccccc0" ALIGN=center>
  33     <A NAME="notworking"> <BIG><B>
  34                 uClibc Frequently Asked Questions (FAQ)
  35     </font>
  36     </A></B></BIG>
  37 </TD></TR>
  38 <TR><TD BGCOLOR="#eeeee0">
  39
  40 <p>
  41 This is a collection of some of the frequently asked questions
  42 about uClibc.  Some of the questions even have answers. If you
  43 have additions to this FAQ document, we would love to add them,
  44 <br>
  45 When you are done, <a href="http://uclibc.org/">you can click here to return
  46 to the uClibc home page.</a>
  47
  48 <p>
  49 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  50     <B>
  51     What platforms does uClibc run on?
  52     </B>
  53 </TD></TR>
  54 <TR><TD BGCOLOR="#eeeee0">
  55
  56     Currently uClibc runs on alpha, ARM, cris, h8300, i386, i960, m68k,
  57     mips/mipsel, PowerPC, SH, SPARC, and v850 processors.
  58
  59
  60 <p>
  61 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  62     <B>
  63     Why is it called uClibc?
  64     </B>
  65 </TD></TR>
  66 <TR><TD BGCOLOR="#eeeee0">
  67
  68     The letter 'u' is short for µ (the greek letter "mu").  µ is commonly used
  69     as the abbreviation for the word "micro".  The capital "C" is short for
  70     "controller".  So the name uClibc is sortof an abbreviation for "the
  71     microcontroller C library".  For simplicity, uClibc is pronounced
  72     "yew-see-lib-see".
  73     <p>
  74     The name is partly historical, since uClibc was originally
  75     created to support <a href="http://www.uclinux.org">µClinux</a>, a port of
  76     Linux for MMU-less microcontrollers such as the Dragonball, Coldfire, and
  77     ARM7TDMI.  These days, uClibc also works just fine on normal Linux systems
  78     (such as i386, ARM, and PowerPC), but we couldn't think of a better name.
  79
  80 <p>
  81 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  82     <B>
  83     Why are you doing this?  What's wrong with glibc?
  84     </B>
  85 </TD></TR>
  86 <TR><TD BGCOLOR="#eeeee0">
  87
  88     Initially, the project began since the GNU C library lacked support for
  89     MMU-less systems, and because glibc is very large.  The GNU C library is
  90     designed with a very different set of goals then uClibc.  The GNU C library
  91     is a great piece of software, make no mistake.  It is compliant with just
  92     about every standard ever created, and runs on just about every operating
  93     system and architecture -- no small task!  But there is a price to be paid
  94     for that.  It is quite a large library, and keeps getting larger with each
  95     release.  It does not even pretend to target embedded systems.  To quote
  96     from Ulrich Drepper, the maintainer of GNU libc: "...glibc is not the right
  97     thing for [an embedded OS]. It is designed as a native library (as opposed
  98     to embedded).  Many functions (e.g., printf) contain functionality which is
  99     not wanted in embedded systems." 24 May 1999
 100
 101
 102
 103 <p>
 104 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 105     <B>
 106     So uClibc is smaller then glibc?  Doesn't that mean it completely sucks?
 107     How could it be smaller and not suck?
 108     </B>
 109 </TD></TR>
 110 <TR><TD BGCOLOR="#eeeee0">
 111
 112     uClibc and glibc have different goals.  glibc strives for features
 113     and performance, and is targeted for desktops and servers with
 114     (these days) lots of resources.  It also strives for ABI stability.
 115
 116     <p>
 117
 118     On the other hand, the goal of uClibc is to provide as much functionality
 119     as possible in a small amount of space, and it is intended primarily for
 120     embedded use.  It is also highly configurable in supported features, at the
 121     cost of ABI differences for different configurations.  uClibc has been
 122     designed from the ground up to be a C library for embedded Linux.  We don't
 123     need to worry about things like MS-DOS support, or BeOS, or AmigaOs any
 124     other system.  This lets us cut out a lot of complexity and very carefully
 125     optimize for Linux.
 126
 127     <p>
 128
 129     In other cases, uClibc
 130     leaves certain features (such as full C99 Math library support, wordexp,
 131     IPV6, and RPC support) disabled by default.  Those features can be enabled
 132     for people that need them, but are otherwise disabled to save space.
 133
 134     <p>
 135
 136     Some of the space savings in uClibc is obtained at the cost of performance,
 137     and some is due to sacrificing features.  Much of it comes from aggressive
 138     refactoring of code to eliminate redundancy.  In regards to locale data,
 139     elimination of redundant data storage resulted in substantial space
 140     savings.  The result is a libc that currently includes the features needed
 141     by nearly all applications and yet is considerably smaller than glibc.  To
 142     compare "apples to apples", if you take uClibc and compile in locale data
 143     for about 170 UTF-8 locales, then uClibc will take up about 570k.  If you
 144     take glibc and add in locale data for the same 170 UTF-8 locales, you will
 145     need over 30MB!!!
 146
 147     <p>
 148
 149     The end result is a C library that will compile just about everything you
 150     throw at it, that looks like glibc to application programs when you
 151     compile, and is many times smaller.
 152
 153
 154
 155 <p>
 156 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 157     <B>
 158     Why should I use uClibc?
 159     </B>
 160 </TD></TR>
 161 <TR><TD BGCOLOR="#eeeee0">
 162
 163     I don't know if you should use uClibc or not.  It depends on your needs.
 164     If you are building an embedded Linux system and you are tight on space, then
 165     using uClibc instead if glibc may be a very good idea.
 166
 167     <p>
 168
 169     If you are building an embedded Linux system and you find that
 170     glibc is eating up too much space, you should consider using
 171     uClibc.  If you are building a huge fileserver with 12 Terabytes
 172     of storage, then using glibc may make more sense.  Unless, for
 173     example, that 12 Terabytes will be Network Attached Storage and
 174     you plan to burn Linux into the system's firmware...
 175
 176
 177
 178 <p>
 179 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 180     <B>
 181     If I use uClibc, do I have to release all my source code to the world for
 182     free?  I want to create a closed source commercial application and I want
 183     to protect my intellectual property.
 184     </B>
 185 </TD></TR>
 186 <TR><TD BGCOLOR="#eeeee0">
 187
 188     No, you do not need to give away your application source code just because
 189     you use uClibc and/or run on Linux.  uClibc is licensed under the <a
 190     href="http://www.gnu.org/copyleft/lesser.html">Lesser GPL</a> licence, just
 191     like the GNU C library (glibc).  Please read this licence, or have a lawyer
 192     read this licence if you have any questions.  Here is my brief summary...
 193     Using shared libraries makes complying with the license easy.  You can
 194     distribute a closed source application which is linked with an unmodified
 195     uClibc shared library.  In this case, you do not need to give away any
 196     source code for your application or for the uClibc library.  Please
 197     consider sharing some of the money you make with us!  :-)
 198     <p>
 199
 200     If you make any changes to uClibc, and distribute uClibc or distribute any
 201     applications using your modified version, you must also distribute the
 202     source code for uClibc containing all of your changes.
 203     <p>
 204
 205     If you distribute an application which has uClibc statically linked, you
 206     must also make your application available as an object file which can later
 207     be re-linked against updated versions of uClibc.  This will (in theory)
 208     allow your customers to apply uClibc bug fixes to your application.  You do
 209     not need to make the application object file available to everyone, just to
 210     those you gave the fully linked application.
 211
 212
 213 <p>
 214 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 215     <B>
 216     Can I use it on my x86 development system?
 217     </B>
 218 </TD></TR>
 219 <TR><TD BGCOLOR="#eeeee0">
 220
 221     Sure!  In fact, this can be very nice during development.  By
 222     installing uClibc on your development system, you can be sure that
 223     the code you are working on will actually run when you deploy it
 224     your target system.
 225
 226
 227
 228 <p>
 229 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 230     <B>
 231     Does uClibc support shared libraries?
 232     </B>
 233 </TD></TR>
 234 <TR><TD BGCOLOR="#eeeee0">
 235
 236     Yes.  uClibc has native shared library support on i386, ARM, mips/mipsel,
 237     SH, CRIS, and PowerPC processors.  Other architectures can use shared libraries
 238     but will need to use the GNU libc shared library loader.
 239     <p>
 240     Shared Libraries are not currently supported by uClibc on MMU-less systems.
 241     <a href="http://www.snapgear.com/">SnapGear</a> has implemented
 242     shared library support for MMU-less systems, however, so if you need MMU-less
 243     shared library support they may be able to help.
 244
 245
 246 <p>
 247 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 248     <B>
 249     How do I compile programs with uClibc?
 250     </B>
 251 </TD></TR>
 252 <TR><TD BGCOLOR="#eeeee0">
 253
 254     The easiest way is to use the compiler wrapper built by uClibc.  Instead of
 255     using your usual compiler or cross compiler, you can use i386-uclibc-gcc,
 256     (or whatever is appropriate for your target architecture) and your
 257     applications will auto-magically link against uClibc.  You can also
 258     build your own native uClibc toolchain.  Just download the uClibc toolchain
 259     builder from
 260     <a href="/cgi-bin/cvsweb/toolchain/">uClibc toolchain builder</a>,
 261     or the uClibc buildroot system from
 262     <a href="/cgi-bin/cvsweb/buildroot/">uClibc buildroot system</a>,
 263     adjust the Makefile settings to match your target system, and then run 'make'.
 264     <p>
 265     If you want to be <em>really</em> lazy and start using uClibc right
 266     away without needing to compile your own toolchain or anything, you can
 267     grab a copy of the uClibc development systems, currently available for
 268     <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_i386.bz2">i386</a>,
 269     <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_powerpc.bz2">powerpc</a>,
 270     <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_mipsel.bz2">mipsel</a>,
 271     and
 272     <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_arm.bz2">arm</a>.
 273     These are pre-built uClibc only development systems (created using
 274     <a href="/cgi-bin/cvsweb/buildroot/">buildroot</a>), and provide a
 275     really really easy way to get started.  These are about 20 MB bzip2
 276     compressed ext2 filesystems containing all the development software you
 277     need to build your own uClibc applications.  With bash, awk, make, gcc, g++,
 278     autoconf, automake, ncurses, zlib, openssl, openssh, gdb, strace, busybox,
 279     GNU coreutils, GNU tar, GNU grep, etc, these should have pretty much everything
 280     you need to get started building your own applications linked against
 281     uClibc.  You can boot into them, loop mount them, dd them to a spare drive
 282     and use resize2fs to make them fill a partition...  Whatever works best
 283     for you.
 284
 285 <p>
 286 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 287     <B>
 288     Why do I keep getting "sh: can't access tty; job control turned off" errors?
 289     Why doesn't Control-C work within my shell?
 290     </B>
 291 </TD></TR>
 292 <TR><TD BGCOLOR="#eeeee0">
 293
 294     This isn't really a uClibc question, but I'll answer it here anyways.  Job
 295     control will be turned off since your shell can not obtain a controlling
 296     terminal.  This typically happens when you run your shell on /dev/console.
 297     The kernel will not provide a controlling terminal on the /dev/console
 298     device.  Your should run your shell on a normal tty such as tty1 or ttyS0
 299     and everything will work perfectly.  If you <em>REALLY</em> want your shell
 300     to run on /dev/console, then you can hack your kernel (if you are into that
 301     sortof thing) by changing drivers/char/tty_io.c to change the lines where
 302     it sets "noctty = 1;" to instead set it to "0".  I recommend you instead
 303     run your shell on a real console...
 304
 305
 306 <p>
 307 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 308     <B>
 309     How do I make autoconf and automake behave?
 310     </B>
 311 </TD></TR>
 312 <TR><TD BGCOLOR="#eeeee0">
 313
 314     First run
 315     <pre>export PATH=/usr/i386-linux-uclibc/bin:$PATH</pre>
 316     (or similar adjusted for your target architecture) then run you can simply
 317     run autoconf/automake and it should _just work_.  Unfortunately, a large
 318     number of configure scripts (such as the one from openssh) try to execute
 319     test applications using your target C library, even if you are cross-
 320     compiling.  This is bad, since it will prevent these programs from compiling.
 321     You need to complain to the authors of these programs and ask them to fix
 322     their broken configure scripts.
 323
 324
 325
 326
 327 <p>
 328 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 329     <B>
 330     When I run 'ldd' to get a list of the library dependencies for a uClibc
 331     binary, ldd segfaults!  What should I do?
 332     </B>
 333 </TD></TR>
 334 <TR><TD BGCOLOR="#eeeee0">
 335
 336     Use the ldd that is built by uClibc, not your system's one.  When your
 337     system's ldd looks for library dependencies, it actually _runs_ that
 338     program.  This works fine -- usually.  It generally will not work at all
 339     when you have been cross compiling (which is why ldd segfaults).  The ldd
 340     program created by uClibc is cross platform and doesn't even try to run
 341     the target program (like your system one does).  So use the uClibc one
 342     and it will do the right thing, and it won't segfault even when you are
 343     cross compiling.
 344
 345
 346 <p>
 347 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 348     <B>
 349     Why does localtime() return times in UTC even when I have my timezone set?
 350     </B>
 351 </TD></TR>
 352 <TR><TD BGCOLOR="#eeeee0">
 353
 354
 355     The uClibc time functions get timezone information from the TZ environment
 356     variable, as described in the Single Unix Specification Version 3.  See
 357      <a href="http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html">
 358     http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html</a>
 359     for details on valid settings of TZ.  For some additional examples, read
 360     <a href="http://www.uclibc.org/lists/uclibc/2002-August/006261.html">
 361     http://www.uclibc.org/lists/uclibc/2002-August/006261.html</a> in the uClibc
 362     mailing list archive.
 363     You can store the value of TZ in the file '/etc/TZ' and uClibc will then
 364     automagically use the specified setting.
 365
 366
 367 <p>
 368 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 369     <B>
 370     What is the history of uClibc?  Where did it come from?
 371     </B>
 372 </TD></TR>
 373 <TR><TD BGCOLOR="#eeeee0">
 374
 375     The history and origin of uClibc is long and twisty.
 376     In the beginning, there was <a href="http://www.gnu.org/software/libc/libc.html">GNU libc</a>.  Then, libc4
 377     (which later became linux libc 5) forked from GNU libc version 1.07.4, with
 378     additions from 4.4BSD, in order to support Linux.  Later, the <a
 379     href="http://www.cix.co.uk/~mayday/">Linux-8086 C library</a>, which is part of
 380     the <a href="http://www.elks.ecs.soton.ac.uk/">elks project</a>, was created,
 381     which was, apparently, largely written from scratch but also borrowed code from
 382     libc4, glibc, some Atari library code, with bits and pieces from about 20 other
 383     places.  Then uClibc forked off from the Linux-8086 C library in order to run
 384     on <a href="http://www.uclinux.org">µClinux</a>.
 385     <p>
 386
 387     I had for some time been despairing over the state of C libraries in Linux.
 388     GNU libc, the standard, is very poorly suited to embedded systems and
 389     has been getting bigger with every release.  I spent quite a bit of time looking over the
 390     available Open Source C libraries that I knew of (listed below), and none of them really
 391     impressed me.  I felt there was a real vacancy in the embedded Linux ecology.
 392     The closest library to what I imagined an embedded C library should be was
 393     uClibc.  But it had a lot of problems too -- not the least of which was that,
 394     traditionally, uClibc had a complete source tree fork in order to support each
 395     and every new platform.  This resulted in a big mess of twisty versions, all
 396     different.  I decided to fix it and the result is what you see here.
 397     My source tree has now become the official uClibc source tree and it now lives
 398     on cvs.uclinux.org and www.uclibc.org.
 399
 400     <p>
 401
 402     To start with, (with some initial help from <a
 403     href="http://www.uclinux.org/developers/">D. Jeff Dionne</a>), I
 404     ported it to run on i386.  I then grafted in the header files from glibc 2.1.3
 405     and cleaned up the resulting breakage.  This (plus some additional work) has
 406     made it almost completely independent of kernel headers, a large departure from
 407     its traditional tightly-coupled-to-the-kernel origins.  I have written and/or
 408     rewritten a number of things that were missing or broken, and sometimes grafted
 409     in bits of code from the current glibc and libc5.  I have also built a proper
 410     platform abstraction layer, so now you can simply edit the file "Config" and
 411     use that to decide which architecture you will be compiling for, and whether or
 412     not your target has an MMU, and FPU, etc.  I have also added a test suite,
 413     which, though incomplete, is a good start.  Several people have helped by
 414     contributing ports to new architectures, and a lot of work has been done on
 415     adding support for missing features.
 416
 417     <p>
 418
 419     In particular, around the end of 2000, Manuel Novoa III got involved with
 420     uClibc.  One of his first contributions was the original gcc wrapper.
 421     Since then, he has written virtually all of the current uClibc stdio, time,
 422     string, ctype, locale, and wchar-related code, as well as much of stdlib
 423     and various other bits throught the library.
 424
 425     <p>
 426
 427     These days, uClibc is being developed and enhanced by Erik Andersen
 428     and Manuel Novoa III of
 429     <a href="http://codepoet-consulting.com/">CodePoet Consulting</a>
 430     along with the rest of the embedded Linux community.
 431
 432
 433
 434 <p>
 435 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 436     <B>
 437     I demand that you to add &lt;favorite feature&gt; right now!   How come
 438     you don't answer all my questions on the mailing list instantly?  I demand
 439     that you help me with all of my problems <em>Right Now</em>!
 440     </B>
 441 </TD></TR>
 442 <TR><TD BGCOLOR="#eeeee0">
 443
 444     You have not paid us a single cent and yet you still have the
 445     product of nearly two years of work from Erik and Manuel and
 446     many other people.  We are not your slaves!  We work on uClibc
 447     because we find it interesting.  If you go off flaming us, we will
 448     ignore you.
 449
 450
 451 <p>
 452 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 453     <B>
 454     I need you to add &lt;favorite feature&gt;!  Are the uClibc developers willing to
 455     be paid in order to fix bugs or add in &lt;favorite feature&gt;?  Are you willing to provide
 456     support contracts?
 457     </B>
 458 </TD></TR>
 459 <TR><TD BGCOLOR="#eeeee0">
 460
 461     Sure!  Now you have our attention!  What you should do is contact <a
 462         href="mailto:andersen@codepoet.org">Erik Andersen</a> of <a
 463         href="http://codepoet-consulting.com/">CodePoet Consulting</a> to bid
 464     on your project.  If Erik is too busy to personally add your feature, there
 465     are several other active uClibc contributors who will almost certainly be able
 466     to help you out.  Erik can contact them and ask them about their availability.
 467
 468
 469 <p>
 470 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 471     <B>
 472     I think you guys are great and I want to help support your work!
 473     </B>
 474 </TD></TR>
 475 <TR><TD BGCOLOR="#eeeee0">
 476
 477     Wow, that would be great!  You can click here to help support uClibc and/or request features.
 478
 479     <!-- Begin PayPal Logo -->
 480     <center>
 481     <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
 482         <input type="hidden" name="cmd" value="_xclick">
 483         <input type="hidden" name="business" value="andersen@codepoet.org">
 484         <input type="hidden" name="item_name" value="Support uClibc and/or request features">
 485         <input type="hidden" name="image_url" value="https://codepoet-consulting.com/images/codepoet.png">
 486         <input type="hidden" name="no_shipping" value="1">
 487         <input type="image" src="images/donate.png" border="0" name="submit" alt="Make donation using PayPal">
 488     </form>
 489     </center>
 490     <!-- End PayPal Logo -->
 491
 492     If you prefer to contact us directly for payments, hardware donations,
 493     support requests, etc., you can contact
 494     <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> here.
 495
 496 <p>
 497 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 498     <B>
 499         Ok, I'm done reading all these questions.
 500     </B>
 501 </TD></TR>
 502 <TR><TD BGCOLOR="#eeeee0">
 503
 504 <a href="http://uclibc.org/">Well then, click here to return to the uClibc home page.</a>
 505
 506
 507
 508 <!-- End things -->
 509
 510 </TD></TR>
 511 </TABLE>
 512 </P>
 513
 514
 515
 516 <!-- Footer -->
 517 <HR>
 518 <TABLE WIDTH="100%">
 519     <TR>
 520         <TD>
 521             <font size="-1" face="arial, helvetica, sans-serif">
 522             Mail all comments, insults, suggestions and bribes to
 523             <a href="mailto:andersen@codepoet.org">Erik Andersen</a><BR>
 524             </font>
 525         </TD>
 526
 527         <TD>
 528             <a href="http://www.vim.org"><img border=0 width=90 height=36
 529             src="images/written.in.vi.png"
 530             alt="This site created with the vi editor"></a>
 531         </TD>
 532
 533         <TD>
 534             <a href="http://www.gimp.org/"><img border=0 width=90 height=36
 535             src="images/gfx_by_gimp.png" alt="Graphics by GIMP"></a>
 536         </TD>
 537
 538         <TD>
 539             <a href="http://www.linuxtoday.com"><img width=90 height=36
 540             src="images/ltbutton2.png" alt="Linux Today"></a>
 541         </TD>
 542
 543         <TD>
 544             <p><a href="http://slashdot.org"><img width=90 height=36
 545             src="images/sdsmall.png" alt="Slashdot"></a>
 546         </TD>
 547
 548         <TD>
 549             <a href="http://freshmeat.net"><img width=90 height=36
 550             src="images/fm.mini.png" alt="Freshmeat"></a>
 551         </TD>
 552
 553     </TR>
 554 </TABLE>
 555
 556
 557 </CENTER>
 558 </BODY>
 559 </HTML>
 560
 561
 562