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 arm, i386, m68k, mipsel, powerpc, sh,
  57     sparc, and v850.
  58
  59
  60 <p>
  61 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  62     <B>
  63     Does uClibc support shared libraries?
  64     </B>
  65 </TD></TR>
  66 <TR><TD BGCOLOR="#eeeee0">
  67
  68     Yes.  uClibc has shared library support on x86, arm, and powerpc.
  69     Shared Libraries are _not_ currently supported on MMU-less systems.
  70
  71
  72
  73 <p>
  74 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  75     <B>
  76     Why is it called uClibc?
  77     </B>
  78 </TD></TR>
  79 <TR><TD BGCOLOR="#eeeee0">
  80
  81     The letter 'u' is short for µ (the greek letter "mu").  µ is commonly used
  82     as the abbreviation for the word "micro".  The capital "C" is short for
  83     "controller".  So you uClibc is simply the microcontroller C library.
  84     This is because uClibc was originaly created to support uClinux, a port of
  85     Linux for MMU-less microcontrollers such as the Dragonball, Coldfire, and
  86     ARM7TDMI.  For simplicity, it is pronounced "yew-see-lib-see".
  87
  88
  89
  90 <p>
  91 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  92     <B>
  93     Can I use it on my desktop x86 system?
  94     </B>
  95 </TD></TR>
  96 <TR><TD BGCOLOR="#eeeee0">
  97
  98     Sure!  In fact, this can be very nice during development.  By using it on
  99     your development system, you can be sure that the code you are working on
 100     will actually run when you deploy it your target system.
 101
 102
 103
 104 <p>
 105 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 106     <B>
 107     Why are you doing this?  Whats wrong with glibc?
 108     </B>
 109 </TD></TR>
 110 <TR><TD BGCOLOR="#eeeee0">
 111
 112     The inital reason, was that glibc does not support MMU-less systems.  But
 113     also because uClibc is so much smaller then the GNU C library.  The GNU C
 114     library has a different set of goals then uClibc.  The GNU C library is a
 115     great piece of software.  It complies with just about every standard ever
 116     created, and runs on just about every operating system as well -- no small
 117     task!  But there is a price to be paid for that.  It is quite a large
 118     library, and keeps getting larger with each release.  It does not even
 119     pretend to target embedded systems.  To quote from Ulrich Drepper, the
 120     maintainer of GNU libc: "...glibc is not the right thing for [an embedded
 121     OS]. It is designed as a native library (as opposed to embedded).  Many
 122     functions (e.g., printf) contain functionality which is not wanted in
 123     embedded systems." 24 May 1999
 124
 125
 126
 127 <p>
 128 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 129     <B>
 130     So uClibc is smaller then glibc?  Doesn't that mean it completely sucks?
 131     How could it be smaller and not suck?
 132     </B>
 133 </TD></TR>
 134 <TR><TD BGCOLOR="#eeeee0">
 135
 136     uClibc has been designed from the ground up to be a C library for embedded
 137     Linux.  We don't need to worry about whether we support MS-DOS, or Cygwin,
 138     or any other system.  This lets us cut out lots of complexity, and very
 139     carefully optimize for Linux.  By very careful design, we can also take a
 140     few shortcuts.  For example, glibc contains an implementation of the
 141     wordexp() function, in compliance with the Single Unix Specificaion,
 142     version 2.  Well, standards are important.  But so is pragmatism.  The
 143     wordexp function is huge, and yet I am not aware of even one Linux
 144     application that uses wordexp.  So uClibc doesn't provide wordexp().  There
 145     are many similar examples.
 146
 147     Glibc is a general purpose C library, and so as policy things are optimized
 148     for speed.  Most of uClibc's routines have been very carefuly written to
 149     optimize them for size instead of speed.
 150
 151     The end result is a C library that will compile just about everything you
 152     throw at it, that looks like glibc to application programs when you
 153     compile, but is many times smaller.
 154
 155
 156
 157 <p>
 158 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 159     <B>
 160     Why should I use uClibc?
 161     </B>
 162 </TD></TR>
 163 <TR><TD BGCOLOR="#eeeee0">
 164
 165     I don't know if you should use uClibc or not.  It depends on your needs.
 166     If you are building an embedded system, and you are tight on space, then
 167     using uClibc instead if glibc should allow you to use your storage for
 168     other things.
 169
 170     If you are trying to build a ultra fast fileserver for your company that
 171     has 12 Terabytes of storage, then you probably want to use glibc...
 172
 173
 174
 175 <p>
 176 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 177     <B>
 178     I want to create a closed source commercial application and  I want to
 179     protect my intellectual property.  If I use uClibc, don't I have to
 180     release all my source code for free?
 181     </B>
 182 </TD></TR>
 183 <TR><TD BGCOLOR="#eeeee0">
 184
 185     No, you do not need to give away your source code just because you use
 186     uClibc and/or run on Linux.
 187
 188
 189
 190 <p>
 191 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 192     <B>
 193     I want to create a closed source commercial application using uClibc.
 194     Is that legal?
 195     </B>
 196 </TD></TR>
 197 <TR><TD BGCOLOR="#eeeee0">
 198
 199     Yes.  uClibc is licensed under the LGPL, just like GNU libc.  If you are
 200     using uClibc as a shared library, then your closed source application is
 201     100% legal.  Please consider sharing some of the money you make.  :-)
 202
 203     If you are staticly linking your closed source commercial application with
 204     uClibc, then you must take additional steps to comply with the uClibc
 205     license.  You can sell your application as usual, but you must also make
 206     your closed source application available to your customers as an object
 207     file which can then be linked with updated versions of uClibc.  This will
 208     (in theory) allow your customers to later link with updated versions of
 209     uClibc.  You do not need to make the application object file available to
 210     everyone, just to those you gave the fully linked application.
 211
 212
 213
 214 <p>
 215 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 216     <B>
 217     How do I compile stuff?
 218     </B>
 219 </TD></TR>
 220 <TR><TD BGCOLOR="#eeeee0">
 221
 222     The easiest way is to use the compiler wrapper built by uClibc.  Instead of
 223     using your usual compiler or cross compiler, you can use i386-uclibc-gcc,
 224     (or whatever is appropriate for your architecture) and it will automagically
 225     make your program link against uClibc.
 226
 227
 228
 229 <p>
 230 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 231     <B>
 232     How do I make autoconf and automake behave?
 233     </B>
 234 </TD></TR>
 235 <TR><TD BGCOLOR="#eeeee0">
 236
 237     First run
 238     <pre>export PATH=/usr/i386-linux-uclibc/bin:$PATH</pre>
 239     (or similar adjusted for your target architecture) then run you can simply
 240     run autoconf/automake and it should _just work_.
 241
 242
 243
 244 <p>
 245 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 246     <B>
 247     When I run 'ldd' to get a list of the library dependancies for a uClibc
 248     binary, ldd segfaults!  Or it runs my application?  Anyways, it doesn't
 249     work!  What should I do?
 250     </B>
 251 </TD></TR>
 252 <TR><TD BGCOLOR="#eeeee0">
 253
 254     Use the ldd that is built by uClibc, not your system's one.  When your
 255     system's ldd looks for the library dependancies, it actually tries to
 256     _execute_ that program.  This works fine -- usually.  I doesn't work at all
 257     when you are cross compiling (thats why ldd segfaults).  The ldd program
 258     created by uClibc is cross platform and doesn't actually try to run the
 259     target program like your system one does, so it should do the right thing,
 260     and won't segfault, even when you are cross compiling.
 261
 262
 263 <p>
 264 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 265     <B>
 266     What is the history of uClibc?  Where did it come from?
 267     </B>
 268 </TD></TR>
 269 <TR><TD BGCOLOR="#eeeee0">
 270
 271     This history and origin of uClibc is long and twisty.
 272     In the beginning, there was <a href="http://www.gnu.org/software/libc/libc.html">GNU libc</a>.  Then, libc4
 273     (which later became linux libc 5) forked from GNU libc version 1.07.4, with
 274     additions from 4.4BSD, in order to support Linux.  Later, the <a
 275     href="http://www.cix.co.uk/~mayday/">Linux-8086 C library</a>, which is part of
 276     the <a href="http://www.elks.ecs.soton.ac.uk/">elks project</a>, was created,
 277     which was, apparently, largely written from scratch but also borrowed code from
 278     libc4, glibc, some Atari library code, with bits and pieces from about 20 other
 279     places.  Then uClibc forked off from the Linux-8086 C library in order to run
 280     on <a href="http://www.uclinux.org">µClinux</a>.
 281     <p>
 282
 283     I had for some time been despairing over the state of C libraries in Linux.
 284     GNU libc, the standard, is very poorly suited to embedded systems (and it just
 285     gets bigger with every release).  I spent quite a bit of time looking over the
 286     other Open Source C libraries that I knew of (listed below), and none of them really
 287     impressed me.  I felt there was a real vacancy in the embedded Linux ecology.
 288     The closest library to what I imagined an embedded C library should be was
 289     uClibc.  But that had a lot of problems too -- not the least of which was that,
 290     traditionally, uClibc had a complete source tree fork in order to support each
 291     and every new platform, resulting in a big mess of twisty versions, all
 292     different.  I decided to fix it and the result is what you see here.
 293     My source tree has now become the official uClibc source tree and it now lives
 294     on cvs.uclinux.org.
 295
 296     <p>
 297
 298     To start with, (with some initial help from <a
 299     href="http://www.uclinux.org/developers/index.html">D. Jeff Dionne</a>), I
 300     ported it to run on x86.  I then grafted in the header files from glibc 2.1.3
 301     and cleaned up the resulting breakage.  This (plus some additional work) has
 302     made it almost completely independant of kernel headers, a large departure from
 303     its traditional tightly-coupled-to-the-kernel origins.  I have written and/or
 304     rewritten a number of things that were missing or broken, and sometimes grafted
 305     in bits of code from the current glibc and libc5.  I have also built a proper
 306     platform abstraction layer, so now you can simply edit the file "Config" and
 307     use that to decide which architecture you will be compiling for, and whether or
 308     not your target has an MMU, and FPU, etc.  I have also added a test suite,
 309     which, though incomplete, is a good start.  Several people have helped by
 310     contributing ports to new architectures, and a lot of work has been done on
 311     adding support for missing features.
 312
 313
 314
 315 <p>
 316 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 317     <B>
 318     I need you to add &lt;favorite feature&gt; now!   How come you don't answer all my
 319     questions on the mailing list withing 5 minutes?  I demand that you help me <em>Right Now</em>!
 320     </B>
 321 </TD></TR>
 322 <TR><TD BGCOLOR="#eeeee0">
 323
 324     You have not paid us a single cent and yet you still have the product of
 325     over year and a half of work from Erik and Manuel and lots of other people.
 326     How dare you treat us that way!  We work on uClibc because we find it
 327     interesting.  If you go off flaming us, we will ignore you.
 328
 329
 330
 331 <p>
 332 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 333     <B>
 334     I need you to add &lt;favorite feature&gt;!  Are the uClibc developers willing to
 335     be paid in order to add in &lt;favorite feature&gt;?  Are you willing to provide
 336     support contracts?
 337     </B>
 338 </TD></TR>
 339 <TR><TD BGCOLOR="#eeeee0">
 340
 341     Sure!  Now you have our attention!  What you should do is contact <a
 342         href="mailto:andersen@codepoet.org">Erik Andersen</a> of <a
 343         href="http://codepoet-consulting.com/">CodePoet Consulting</a> to bid
 344     on your project.  If Erik is too busy to personally add your feature, there
 345     are several other active uClibc contributors who may be able to help you out.
 346     Erik can contact them and ask them about their availability.
 347
 348
 349 <p>
 350 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 351     <B>
 352     I think you guys are great and I want to help support your work!
 353     </B>
 354 </TD></TR>
 355 <TR><TD BGCOLOR="#eeeee0">
 356
 357     Wow, that would be great!  You can click here to help support uClibc and/or request features.
 358
 359     <!-- Begin PayPal Logo -->
 360     <center>
 361     <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
 362         <input type="hidden" name="cmd" value="_xclick">
 363         <input type="hidden" name="business" value="andersen@codepoet.org">
 364         <input type="hidden" name="item_name" value="Support uClibc and/or request features">
 365         <input type="hidden" name="image_url" value="https://codepoet-consulting.com/images/codepoet.png">
 366         <input type="hidden" name="no_shipping" value="1">
 367         <input type="image" src="images/donate.png" border="0" name="submit" alt="Make donation using PayPal">
 368     </form>
 369     </center>
 370     <!-- End PayPal Logo -->
 371
 372     If you prefer to contact us directly for payments (we have a credit card machine so
 373     you can avoid online payments), hardware donations, support requests, etc., you can
 374     contact <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> here.
 375
 376 <p>
 377 <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
 378     <B>
 379         Ok, I'm done reading all these questions.
 380     </B>
 381 </TD></TR>
 382 <TR><TD BGCOLOR="#eeeee0">
 383
 384 <a href="http://uclibc.org/">Well then, click here to return to the uClibc home page.</a>
 385
 386
 387
 388 <!-- End things -->
 389
 390 </TD></TR>
 391 </TABLE>
 392 </P>
 393
 394
 395
 396 <!-- Footer -->
 397 <HR>
 398 <TABLE WIDTH="100%">
 399     <TR>
 400         <TD>
 401             <font size="-1" face="arial, helvetica, sans-serif">
 402             Mail all comments, insults, suggestions and bribes to
 403             <a href="mailto:andersen@codepoet.org">Erik Andersen</a><BR>
 404             </font>
 405         </TD>
 406
 407         <TD>
 408             <a href="http://www.vim.org"><img border=0 width=90 height=36
 409             src="images/written.in.vi.png"
 410             alt="This site created with the vi editor"></a>
 411         </TD>
 412
 413         <TD>
 414             <a href="http://www.gimp.org/"><img border=0 width=90 height=36
 415             src="images/gfx_by_gimp.png" alt="Graphics by GIMP"></a>
 416         </TD>
 417
 418         <TD>
 419             <a href="http://www.linuxtoday.com"><img width=90 height=36
 420             src="images/ltbutton2.png" alt="Linux Today"></a>
 421         </TD>
 422
 423         <TD>
 424             <p><a href="http://slashdot.org"><img width=90 height=36
 425             src="images/sdsmall.png" alt="Slashdot"></a>
 426         </TD>
 427
 428         <TD>
 429             <a href="http://freshmeat.net"><img width=90 height=36
 430             src="images/fm.mini.png" alt="Freshmeat"></a>
 431         </TD>
 432
 433     </TR>
 434 </TABLE>
 435
 436
 437 </CENTER>
 438 </BODY>
 439 </HTML>
 440
 441
 442