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, i386, i960, h8300, m68k, mips/mipsel,
  57     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     Can I use it on my desktop i386 system?
  84     </B>
  85 </TD></TR>
  86 <TR><TD BGCOLOR="#eeeee0">
  87
  88     Sure!  In fact, this can be very nice during development.  By
  89     installing uClibc on your development system, you can be sure that
  90     the code you are working on will actually run when you deploy it
  91     your target system.
  92
  93
  94
  95 <p>
  96 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  97     <B>
  98     Does uClibc support shared libraries?
  99     </B>
 100 </TD></TR>
 101 <TR><TD BGCOLOR="#eeeee0">
 102
 103     Yes.  uClibc has native shared library support on i386, ARM, mips/mipsel,
 104     SH, and PowerPC processors.  Other architectures can use shared libraries
 105     but will need to use the GNU libc shared library loader.
 106     <p>
 107     Shared Libraries are not currently supported by uClibc on MMU-less systems.
 108     <a href="http://www.snapgear.com/">SnapGear</a> has implemented
 109     shared library support for MMU-less systems, however, so if you need MMU-less
 110     shared library support they may be able to help.
 111
 112
 113 <p>
 114 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 115     <B>
 116     Why are you doing this?  What's wrong with glibc?
 117     </B>
 118 </TD></TR>
 119 <TR><TD BGCOLOR="#eeeee0">
 120
 121     Initially, the project began since the GNU C library lacks support for
 122     MMU-less systems, and because glibc is very large.  The GNU C library is
 123     designed with a very different set of goals then uClibc.  The GNU C library
 124     is a great piece of software, make no mistake.  It is compliant with just
 125     about every standard ever created, and runs on just about every operating
 126     system and architecture -- no small task!  But there is a price to be paid
 127     for that.  It is quite a large library, and keeps getting larger with each
 128     release.  It does not even pretend to target embedded systems.  To quote
 129     from Ulrich Drepper, the maintainer of GNU libc: "...glibc is not the right
 130     thing for [an embedded OS]. It is designed as a native library (as opposed
 131     to embedded).  Many functions (e.g., printf) contain functionality which is
 132     not wanted in embedded systems." 24 May 1999
 133
 134
 135
 136 <p>
 137 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 138     <B>
 139     So uClibc is smaller then glibc?  Doesn't that mean it completely sucks?
 140     How could it be smaller and not suck?
 141     </B>
 142 </TD></TR>
 143 <TR><TD BGCOLOR="#eeeee0">
 144
 145     uClibc has been designed from the ground up to be a C library for
 146     embedded Linux.  We don't need to worry about things like MS-DOS
 147     support, or BeOS, or AmigaOs any other system.  This lets us cut out
 148     a lot of complexity and very carefully optimize for Linux.  By very
 149     careful design, we can also take a few shortcuts.  For example, glibc
 150     contains an implementation of the wordexp() function, in compliance
 151     with the Single Unix Specification, version 3.  Well, standards are
 152     important.  But so is pragmatism.  The wordexp function is huge, yet I
 153     am not aware of even one Linux application that uses it!  So uClibc
 154     doesn't provide wordexp().  There are many similar examples.  In other
 155     cases, uClibc leaves certain features (such as full C99 Math library
 156     support, IPV6, and RPC support) disabled by default.  Those features
 157     can be enabled for people that need them, but are otherwise disabled to
 158     save space.
 159
 160     <p>
 161
 162     Glibc is a general purpose C library, and so as policy things are optimized
 163     for speed.  Most of uClibc's routines have been very carefully written to
 164     optimize them for size instead.
 165
 166     <p>
 167
 168     The end result is a C library that will compile just about everything you
 169     throw at it, that looks like glibc to application programs when you
 170     compile, but is many times smaller.
 171
 172
 173
 174 <p>
 175 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 176     <B>
 177     Why should I use uClibc?
 178     </B>
 179 </TD></TR>
 180 <TR><TD BGCOLOR="#eeeee0">
 181
 182     I don't know if you should use uClibc or not.  It depends on your needs.
 183     If you are building an embedded Linux system and you are tight on space, then
 184     using uClibc instead if glibc may be a very good idea.
 185
 186     If you are trying to build a huge fileserver for your company that will
 187     have 12 Terabytes of storage, then using glibc may make more sense.
 188     Unless, for example, that 12 Terabytes will be Network Attached Storage
 189     and you plan to burn Linux into the system's firmware...
 190
 191
 192
 193 <p>
 194 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 195     <B>
 196     If I use uClibc, do I have to release all my source code to the world for
 197     free?  I want to create a closed source commercial application and I want
 198     to protect my intellectual property.
 199     </B>
 200 </TD></TR>
 201 <TR><TD BGCOLOR="#eeeee0">
 202
 203     No, you do not need to give away your source code just because you use
 204     uClibc and/or run on Linux.  uClibc is licensed under the LGPL, just like
 205     GNU libc.  Using shared libraries makes complying with the license easy.
 206     If you are using uClibc as a shared library, then your closed source
 207     application is 100% legal.  Please consider sharing some of the money you
 208     make with us!  :-)
 209
 210     <p>
 211
 212     If you are statically linking your closed source application with
 213     uClibc, then you must take additional steps to comply with the uClibc
 214     license.  You may sell your statically linked application as usual, but
 215     you must also make your application available to your customers as an
 216     object file which can later be re-linked against updated versions of
 217     uClibc.  This will (in theory) allow your customers to apply uClibc bug
 218     fixes to your application.  You do not need to make the application
 219     object file available to everyone, just to those you gave the fully
 220     linked application.
 221
 222
 223 <p>
 224 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 225     <B>
 226     How do I compile programs with uClibc?
 227     </B>
 228 </TD></TR>
 229 <TR><TD BGCOLOR="#eeeee0">
 230
 231     The easiest way is to use the compiler wrapper built by uClibc.  Instead of
 232     using your usual compiler or cross compiler, you can use i386-uclibc-gcc,
 233     (or whatever is appropriate for your target architecture) and your
 234     applications will auto-magically link against uClibc.  You can also
 235     build your own native uClibc toolchain.  Just download the uClibc toolchain
 236     builder from <a href="http://www.uclibc.org/downloads/toolchain/">
 237     http://www.uclibc.org/downloads/toolchain/</a>, ajust the Makefile settings
 238     to match your target system, and then run 'make'.
 239
 240
 241 <p>
 242 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 243     <B>
 244     I have code that uses constructors and destructors.  Why is it
 245     when I use uClibc, the ctors/dtors do not run?
 246     </B>
 247 </TD></TR>
 248 <TR><TD BGCOLOR="#eeeee0">
 249
 250     The uClibc compiler wrapper toolchain by default, does not
 251     enable constructor and destructor support for C code.  It
 252     only enables ctors/dtors support by default for C++ code.
 253     If you have C code that uses ctors/dtors and you wish to use
 254     the uClibc compiler wrapper toolchain, you will need to add
 255     the <b>--uclibc-ctors</b> option to the gcc command line.  i.e.
 256
 257 <PRE>
 258         $ cat test.c
 259         #include <unistd.h>
 260
 261         void __attribute__((constructor)) my_ctor(void)
 262         {
 263             char msg[]="I am a constructor!\n";
 264             write(2, msg, sizeof(msg));
 265         }
 266
 267         int main(void)
 268         {
 269             _exit(42);
 270         }
 271
 272         $ /usr/i386-linux-uclibc/bin/i386-uclibc-gcc --uclibc-ctors ./test.c -o test
 273         $ ./test
 274         I am a constructor!
 275 </PRE>
 276
 277     Another option is to build a native uClibc toolchain.  Native toolchains
 278     always enable ctors/dtors support, even for C code.
 279
 280
 281
 282 <p>
 283 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 284     <B>
 285     How do I make autoconf and automake behave?
 286     </B>
 287 </TD></TR>
 288 <TR><TD BGCOLOR="#eeeee0">
 289
 290     First run
 291     <pre>export PATH=/usr/i386-linux-uclibc/bin:$PATH</pre>
 292     (or similar adjusted for your target architecture) then run you can simply
 293     run autoconf/automake and it should _just work_.
 294
 295
 296
 297 <p>
 298 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 299     <B>
 300     When I run 'ldd' to get a list of the library dependencies for a uClibc
 301     binary, ldd segfaults!  What should I do?
 302     </B>
 303 </TD></TR>
 304 <TR><TD BGCOLOR="#eeeee0">
 305
 306     Use the ldd that is built by uClibc, not your system's one.  When your
 307     system's ldd looks for library dependencies, it actually _runs_ that
 308     program.  This works fine -- usually.  It generally will not work at all
 309     when you have been cross compiling (which is why ldd segfaults).  The ldd
 310     program created by uClibc is cross platform and doesn't even try to run
 311     the target program (like your system one does).  So use the uClibc one
 312     and it will do the right thing, and it won't segfault even when you are
 313     cross compiling.
 314
 315
 316 <p>
 317 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 318     <B>
 319     Why does localtime() return times in UTC even when I have my timezone set?
 320     </B>
 321 </TD></TR>
 322 <TR><TD BGCOLOR="#eeeee0">
 323
 324
 325     The uClibc time functions get timezone information from the TZ environment
 326     variable, as described in the Single Unix Specification Version 3.  See
 327      <a href="http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html">
 328     http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html</a>
 329     for details on valid settings of TZ.  For some additional examples, read
 330     <a href="http://www.uclibc.org/lists/uclibc/2002-August/006261.html">
 331     http://www.uclibc.org/lists/uclibc/2002-August/006261.html</a> in the uClibc
 332     mailing list archive.
 333
 334
 335 <p>
 336 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 337     <B>
 338     What is the history of uClibc?  Where did it come from?
 339     </B>
 340 </TD></TR>
 341 <TR><TD BGCOLOR="#eeeee0">
 342
 343     The history and origin of uClibc is long and twisty.
 344     In the beginning, there was <a href="http://www.gnu.org/software/libc/libc.html">GNU libc</a>.  Then, libc4
 345     (which later became linux libc 5) forked from GNU libc version 1.07.4, with
 346     additions from 4.4BSD, in order to support Linux.  Later, the <a
 347     href="http://www.cix.co.uk/~mayday/">Linux-8086 C library</a>, which is part of
 348     the <a href="http://www.elks.ecs.soton.ac.uk/">elks project</a>, was created,
 349     which was, apparently, largely written from scratch but also borrowed code from
 350     libc4, glibc, some Atari library code, with bits and pieces from about 20 other
 351     places.  Then uClibc forked off from the Linux-8086 C library in order to run
 352     on <a href="http://www.uclinux.org">µClinux</a>.
 353     <p>
 354
 355     I had for some time been despairing over the state of C libraries in Linux.
 356     GNU libc, the standard, is very poorly suited to embedded systems and
 357     has been getting bigger with every release.  I spent quite a bit of time looking over the
 358     available Open Source C libraries that I knew of (listed below), and none of them really
 359     impressed me.  I felt there was a real vacancy in the embedded Linux ecology.
 360     The closest library to what I imagined an embedded C library should be was
 361     uClibc.  But it had a lot of problems too -- not the least of which was that,
 362     traditionally, uClibc had a complete source tree fork in order to support each
 363     and every new platform.  This resulted in a big mess of twisty versions, all
 364     different.  I decided to fix it and the result is what you see here.
 365     My source tree has now become the official uClibc source tree and it now lives
 366     on cvs.uclinux.org and www.uclibc.org.
 367
 368     <p>
 369
 370     To start with, (with some initial help from <a
 371     href="http://www.uclinux.org/developers/">D. Jeff Dionne</a>), I
 372     ported it to run on i386.  I then grafted in the header files from glibc 2.1.3
 373     and cleaned up the resulting breakage.  This (plus some additional work) has
 374     made it almost completely independent of kernel headers, a large departure from
 375     its traditional tightly-coupled-to-the-kernel origins.  I have written and/or
 376     rewritten a number of things that were missing or broken, and sometimes grafted
 377     in bits of code from the current glibc and libc5.  I have also built a proper
 378     platform abstraction layer, so now you can simply edit the file "Config" and
 379     use that to decide which architecture you will be compiling for, and whether or
 380     not your target has an MMU, and FPU, etc.  I have also added a test suite,
 381     which, though incomplete, is a good start.  Several people have helped by
 382     contributing ports to new architectures, and a lot of work has been done on
 383     adding support for missing features.
 384
 385     <p>
 386
 387     These days, uClibc is being developed and enhanced by Erik Andersen of
 388     <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> along
 389     with the rest of the embedded Linux community.
 390
 391
 392
 393 <p>
 394 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 395     <B>
 396     I demand that you to add &lt;favorite feature&gt; right now!   How come
 397     you don't answer all my questions on the mailing list instantly?  I demand
 398     that you help me with all of my problems <em>Right Now</em>!
 399     </B>
 400 </TD></TR>
 401 <TR><TD BGCOLOR="#eeeee0">
 402
 403     You have not paid us a single cent and yet you still have the
 404     product of nearly two years of work from Erik and Manuel and
 405     many other people.  We are not your slaves!  We work on uClibc
 406     because we find it interesting.  If you go off flaming us, we will
 407     ignore you.
 408
 409
 410 <p>
 411 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 412     <B>
 413     I need you to add &lt;favorite feature&gt;!  Are the uClibc developers willing to
 414     be paid in order to fix bugs or add in &lt;favorite feature&gt;?  Are you willing to provide
 415     support contracts?
 416     </B>
 417 </TD></TR>
 418 <TR><TD BGCOLOR="#eeeee0">
 419
 420     Sure!  Now you have our attention!  What you should do is contact <a
 421         href="mailto:andersen@codepoet.org">Erik Andersen</a> of <a
 422         href="http://codepoet-consulting.com/">CodePoet Consulting</a> to bid
 423     on your project.  If Erik is too busy to personally add your feature, there
 424     are several other active uClibc contributors who will almost certainly be able
 425     to help you out.  Erik can contact them and ask them about their availability.
 426
 427
 428 <p>
 429 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 430     <B>
 431     I think you guys are great and I want to help support your work!
 432     </B>
 433 </TD></TR>
 434 <TR><TD BGCOLOR="#eeeee0">
 435
 436     Wow, that would be great!  You can click here to help support uClibc and/or request features.
 437
 438     <!-- Begin PayPal Logo -->
 439     <center>
 440     <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
 441         <input type="hidden" name="cmd" value="_xclick">
 442         <input type="hidden" name="business" value="andersen@codepoet.org">
 443         <input type="hidden" name="item_name" value="Support uClibc and/or request features">
 444         <input type="hidden" name="image_url" value="https://codepoet-consulting.com/images/codepoet.png">
 445         <input type="hidden" name="no_shipping" value="1">
 446         <input type="image" src="images/donate.png" border="0" name="submit" alt="Make donation using PayPal">
 447     </form>
 448     </center>
 449     <!-- End PayPal Logo -->
 450
 451     If you prefer to contact us directly for payments (Erik has a credit card machine so
 452     you can avoid making payments online), hardware donations, support requests, etc., you can
 453     contact <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> here.
 454
 455 <p>
 456 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 457     <B>
 458         Ok, I'm done reading all these questions.
 459     </B>
 460 </TD></TR>
 461 <TR><TD BGCOLOR="#eeeee0">
 462
 463 <a href="http://uclibc.org/">Well then, click here to return to the uClibc home page.</a>
 464
 465
 466
 467 <!-- End things -->
 468
 469 </TD></TR>
 470 </TABLE>
 471 </P>
 472
 473
 474
 475 <!-- Footer -->
 476 <HR>
 477 <TABLE WIDTH="100%">
 478     <TR>
 479         <TD>
 480             <font size="-1" face="arial, helvetica, sans-serif">
 481             Mail all comments, insults, suggestions and bribes to
 482             <a href="mailto:andersen@codepoet.org">Erik Andersen</a><BR>
 483             </font>
 484         </TD>
 485
 486         <TD>
 487             <a href="http://www.vim.org"><img border=0 width=90 height=36
 488             src="images/written.in.vi.png"
 489             alt="This site created with the vi editor"></a>
 490         </TD>
 491
 492         <TD>
 493             <a href="http://www.gimp.org/"><img border=0 width=90 height=36
 494             src="images/gfx_by_gimp.png" alt="Graphics by GIMP"></a>
 495         </TD>
 496
 497         <TD>
 498             <a href="http://www.linuxtoday.com"><img width=90 height=36
 499             src="images/ltbutton2.png" alt="Linux Today"></a>
 500         </TD>
 501
 502         <TD>
 503             <p><a href="http://slashdot.org"><img width=90 height=36
 504             src="images/sdsmall.png" alt="Slashdot"></a>
 505         </TD>
 506
 507         <TD>
 508             <a href="http://freshmeat.net"><img width=90 height=36
 509             src="images/fm.mini.png" alt="Freshmeat"></a>
 510         </TD>
 511
 512     </TR>
 513 </TABLE>
 514
 515
 516 </CENTER>
 517 </BODY>
 518 </HTML>
 519
 520
 521