1 <!--#include file="header.html" -->
4 <h3>Frequently Asked Questions</h3>
6 This is a collection of some of the most frequently asked questions
7 about uClibc. Some of the questions even have answers. If you
8 have additions to this FAQ document, we would love to add them,
11 <li><a href="#naming">Why is it called uClibc?</a>
12 <li><a href="#platforms">What platforms does uClibc run on?</a>
13 <li><a href="#why">Why are you doing this? What's wrong with glibc?</a>
14 <li><a href="#doesnt_suck">So uClibc is smaller then glibc? Doesn't that mean it
15 completely sucks? How could it be smaller and not suck?</a>
16 <li><a href="#why_should_i">Why should I use uClibc?</a>
17 <li><a href="#licensing">If I use uClibc, do I have to release all my source code to the world for
18 free? I want to create a closed source commercial application and I want
19 to protect my intellectual property.</a>
20 <li><a href="#development">Can I use it on my x86 development system?</a>
21 <li><a href="#shared"> Does uClibc support shared libraries?</a>
22 <li><a href="#compiling">How do I compile programs with uClibc?</a>
23 <li><a href="#toolchain">Do I really need to build a uClibc toolchain?</a>
24 <li><a href="#wrapper">What happened to the old toolchain wrapper?</a>
25 <li><a href="#dev_systems">Is a pre-compiled uClibc development system available?</a>
26 <li><a href="#bugs">I think I found a bug in uClibc! What should I do?!</a>
27 <li><a href="#job_control">Why do I keep getting "sh: can't access tty; job control
28 turned off" errors? Why doesn't Control-C work within my shell?</a>
29 <li><a href="#autoconf">How do I make autoconf and automake behave?</a>
30 <li><a href="#ldd">When I run 'ldd' to get a list of the library dependencies
31 for a uClibc binary, ldd segfaults! What should I do?</a>
32 <li><a href="#timezones">Why does localtime() return times in UTC even when I have my timezone set?</a>
33 <li><a href="#history">What is the history of uClibc? Where did it come from?</a>
34 <li><a href="#demanding">I demand that you to add <favorite feature> right now! How come
35 you don't answer all my questions on the mailing list instantly? I demand
36 that you help me with all of my problems <em>Right Now</em>!</a>
37 <li><a href="#helpme">I need help with uClibc! What should I do?</a>
38 <li><a href="#contracts">I need you to add <favorite feature>! Are the uClibc developers willing to
39 be paid in order to fix bugs or add in <favorite feature>? Are you willing to provide
40 support contracts?</a>
41 <li><a href="#support">I think you guys are great and I want to help support your work!</a>
49 <h2><a name="naming">Why is it called uClibc?</a></h2>
52 The letter 'u' is short for µ (the greek letter "mu"). µ is commonly used
53 as the abbreviation for the word "micro". The capital "C" is short for
54 "controller". So the name uClibc is sortof an abbreviation for "the
55 microcontroller C library". For simplicity, uClibc is pronounced
58 The name is partly historical, since uClibc was originally
59 created to support <a href="http://www.uclinux.org">µClinux</a>, a port of
60 Linux for MMU-less microcontrollers such as the Dragonball, Coldfire, and
61 ARM7TDMI. These days, uClibc also works just fine on normal Linux systems
62 (such as i386, ARM, and PowerPC), but we couldn't think of a better name.
66 <h2><a name="platforms">What platforms does uClibc run on?</a></h2>
70 Currently uClibc runs on alpha, ARM, cris, i386, i960, h8300,
71 m68k, mips/mipsel, PowerPC, SH, SPARC, and v850 processors.
76 <h2><a name="why">Why are you doing this? What's wrong with glibc?</a></h2>
79 Initially, the project began since the GNU C library lacked support for
80 MMU-less systems, and because glibc is very large. The GNU C library is
81 designed with a very different set of goals then uClibc. The GNU C library
82 is a great piece of software, make no mistake. It is compliant with just
83 about every standard ever created, and runs on just about every operating
84 system and architecture -- no small task! But there is a price to be paid
85 for that. It is quite a large library, and keeps getting larger with each
86 release. It does not even pretend to target embedded systems. To quote
87 from Ulrich Drepper, the maintainer of GNU libc: "...glibc is not the right
88 thing for [an embedded OS]. It is designed as a native library (as opposed
89 to embedded). Many functions (e.g., printf) contain functionality which is
90 not wanted in embedded systems." 24 May 1999
96 <h2><a name="doesnt_suck">So uClibc is smaller then glibc? Doesn't that mean it completely sucks?
97 How could it be smaller and not suck?</a></h2>
101 uClibc and glibc have different goals. glibc strives for features
102 and performance, and is targeted for desktops and servers with
103 (these days) lots of resources. It also strives for ABI stability.
107 On the other hand, the goal of uClibc is to provide as much functionality
108 as possible in a small amount of space, and it is intended primarily for
109 embedded use. It is also highly configurable in supported features, at the
110 cost of ABI differences for different configurations. uClibc has been
111 designed from the ground up to be a C library for embedded Linux. We don't
112 need to worry about things like MS-DOS support, or BeOS, or AmigaOs any
113 other system. This lets us cut out a lot of complexity and very carefully
118 In other cases, uClibc leaves certain features (such as full C99 Math
119 library support, wordexp, IPV6, and RPC support) disabled by default.
120 Those features can be enabled for people that need them, but are otherwise
121 disabled to save space.
125 Some of the space savings in uClibc is obtained at the cost of performance,
126 and some is due to sacrificing features. Much of it comes from aggressive
127 refactoring of code to eliminate redundancy. In regards to locale data,
128 elimination of redundant data storage resulted in substantial space
129 savings. The result is a libc that currently includes the features needed
130 by nearly all applications and yet is considerably smaller than glibc. To
131 compare "apples to apples", if you take uClibc and compile in locale data
132 for about 170 UTF-8 locales, then uClibc will take up about 570k. If you
133 take glibc and add in locale data for the same 170 UTF-8 locales, you will
138 The end result is a C library that will compile just about everything you
139 throw at it, that looks like glibc to application programs when you
140 compile, and is many times smaller.
145 <h2><a name="why_should_i">Why should I use uClibc?</a></h2>
148 I don't know if you should use uClibc or not. It depends on your needs.
149 If you are building an embedded Linux system and you are tight on space, then
150 using uClibc instead if glibc may be a very good idea.
154 If you are building an embedded Linux system and you find that
155 glibc is eating up too much space, you should consider using
156 uClibc. If you are building a huge fileserver with 12 Terabytes
157 of storage, then using glibc may make more sense. Unless, for
158 example, that 12 Terabytes will be Network Attached Storage and
159 you plan to burn Linux into the system's firmware...
165 <h2><a name="licensing">If I use uClibc, do I have to release all my source code to the world for
166 free? I want to create a closed source commercial application and I want
167 to protect my intellectual property.</a></h2>
170 No, you do not need to give away your application source code just because
171 you use uClibc and/or run on Linux. uClibc is licensed under the <a
172 href="http://www.gnu.org/copyleft/lesser.html">Lesser GPL</a> licence, just
173 like the GNU C library (glibc). Please read this licence, or have a lawyer
174 read this licence if you have any questions. Here is my brief summary...
175 Using shared libraries makes complying with the license easy. You can
176 distribute a closed source application which is linked with an unmodified
177 uClibc shared library. In this case, you do not need to give away any
178 source code for your application. Please consider sharing some of the
179 money you make with us! :-)
182 If you make any changes to uClibc, and distribute uClibc or distribute any
183 applications using your modified version, you must also distribute the
184 source code for uClibc containing all of your changes.
187 If you distribute an application which has uClibc statically linked, you
188 must also make your application available as an object file which can later
189 be re-linked against updated versions of uClibc. This will (in theory)
190 allow your customers to apply uClibc bug fixes to your application. You do
191 not need to make the application object file available to everyone, just to
192 those you gave the fully linked application.
197 <h2><a name="development">Can I use it on my x86 development system?</a></h2>
200 Sure! In fact, this can be very nice during development. By
201 installing uClibc on your development system, you can be sure that
202 the code you are working on will actually run when you deploy it on
209 <h2><a name="shared"> Does uClibc support shared libraries?</a></h2>
212 Yes. uClibc has native shared library support on i386, ARM, mips,
213 SH, CRIS, and PowerPC processors. Other architectures can use shared
214 libraries but will need to use the GNU libc shared library loader.
216 Shared Libraries are not currently supported by uClibc on MMU-less systems.
217 <a href="http://www.snapgear.com/">SnapGear</a> has implemented
218 shared library support for MMU-less systems, however, so if you need MMU-less
219 shared library support they may be able to help.
224 <h2><a name="compiling">How do I compile programs with uClibc?</a></h2>
227 You will need to have your own uClibc toolchain. A toolchain consists
228 of <a href="http://sources.redhat.com/binutils/">GNU binutils</a>,
229 <a href="http://gcc.gnu.org/">the gcc compiler</a>, and uClibc, all
230 built to produce binaries for your target system linked with uClibc.
231 You can build your own native uClibc toolchain using the
232 <a href="/cgi-bin/cvsweb/buildroot/">uClibc buildroot system</a>.
235 To build your own uClibc toolchain, follow the following simple
238 <li> Point your web browser <a href="/cgi-bin/cvsweb/buildroot/">here</a>,
239 <li> Click on "Download tarball"
240 <li> Unpack the tarball on your Linux system somewhere
241 <li> Edit the Makefile as needed if you wish to change anything.
242 <li> run 'unset CC'. Then run 'unset CXX'. Some Linux systems
243 (i.e. Gentoo) set variables such as 'CC' in the system environment
244 which really messes things up when cross compiling.
245 <li> run 'make menuconfig'
246 <li> Select the things you want to build. If you <em>only</em> want a
247 toolchain, leave everything except the toolchain disabled.
248 <li> save your buildroot configuration.
250 <li> go eat a nice wholesome sandwich, drink a pop, call a friend,
251 play a video game, and generally find something to do. While you
252 are waiting, buildroot will download all the needed source code and
253 then compile things up for you.
254 <li> You should now have a shiny new toolchain, and maybe even a shiny
255 new uClibc based root filesystem or development system, depending on
256 the options you selected.
261 <h2><a name="toolchain">Do I really need to build a uClibc toolchain?</h2>
264 Yes, you really do need to build a toolchain to produce uClibc binaries.
265 We used to provide a toolchain wrapper, but that has been removed due to
266 numerous problems. The uClibc developers have gone to a lot of trouble
268 <a href="/cgi-bin/cvsweb/buildroot/">uClibc buildroot system</a>,
269 which makes it easy to build your own uClibc toolchain and/or an initial
273 Feel free to take the gcc and binutils patches we provide and use them in
274 your own toolchain build system. If you choose to use your own toolchain
275 build system, you will need to use these patches since the upstream GNU
276 binutils and gcc releases do not currently have full support for building a
282 <h2><a name="wrapper">What happened to the old toolchain wrapper?</h2>
285 It is possible in some limited cases to re-use an existing glibc toolchain
286 and subvert it into building uClibc binaries by using gcc commands such as
287 "-nostdlib" and "-nostdinc". In fact, this used to be the recommended
288 method for compiling programs with uClibc, and we made this easy to do by
289 providing a uClibc toolchain wrapper, which attempted to automagically subvert
290 an existing glibc toolchain.
294 This toolchain wrapper was removed from uClibc 0.9.22, and it will not be
295 coming back. This is because it proved impossible to completely subvert an
296 existing toolchain in many cases, and therefore proved to be a real
297 maintainence burder. As uClibc became more capable, the many problems with
298 re-using an existing glibc toolchain led us to conclude that the only safe
299 and sane way to build uClibc binaries was to use a uClibc toolchain.
303 Some discussion on the reasoning behind this decision can be found here:
304 <a href="http://www.uclibc.org/lists/uclibc/2003-October/007315.html">
305 http://www.uclibc.org/lists/uclibc/2003-October/007315.html</a>
306 in the uClibc mailing list archives.
310 <h2><a name="dev_systems">Is a pre-compiled uClibc development system available?</a></h2>
313 If you want to be <em>really</em> lazy and start using uClibc right away
314 without needing to compile your own toolchain or anything, you can grab a
315 pre-compiled uClibc development system. These are currently available for
317 <a href="http://www.uclibc.org/downloads/root_fs_arm.ext2.bz2">arm</a>,
318 <a href="http://www.uclibc.org/downloads/root_fs_armeb.ext2.bz2">armeb</a>,
319 <a href="http://www.uclibc.org/downloads/root_fs_i386.ext2.bz2">i386</a>,
320 <a href="http://www.uclibc.org/downloads/root_fs_mips.ext2.bz2">mips</a>,
321 <a href="http://www.uclibc.org/downloads/root_fs_mipsel.ext2.bz2">mipsel</a>,
322 <a href="http://www.uclibc.org/downloads/root_fs_powerpc.ext2.bz2">powerpc</a>, and
323 <a href="http://www.uclibc.org/downloads/root_fs_sh4.ext2.bz2">sh4</a>.
327 These are bzip2 compressed ext2 filesystems containing all the development
328 software you need to build your own uClibc applications, including: bash, awk,
329 make, gcc, g++, autoconf, automake, ncurses, zlib, openssl, openssh, gdb,
330 strace, busybox, GNU coreutils, GNU tar, GNU grep, etc.
334 Each of these uClibc development systems was created using
335 <a href="/cgi-bin/cvsweb/buildroot/">buildroot</a>, specifically,
336 <a href="http://www.uclibc.org/downloads/buildroot.tar.bz2">buildroot.tar.bz2</a>
337 along with <a href="http://www.uclibc.org/downloads/buildroot-sources">these sources</a>.
341 These development systems should provide pretty much everything you need to get
342 started building your own applications with uClibc. Once you download one of
343 these systems, you can then boot into it, loop mount it, dd it to a spare drive
344 and use a tool such as resize2fs to make it fill a partition... Whatever works
348 The quickest way to get started using a root_fs image (using the i386
349 platform as an example) is:
351 <li>Download root_fs_i386.bz2 from uclibc.org</li>
352 <li>bunzip2 root_fs_i386.bz2</li>
353 <li>mkdir root_fs</li>
355 <li>mount -o loop root_fs_i386 root_fs</li>
356 <li>chroot root_fs /bin/su -</li>
358 Type "exit" to end the chroot session and return to the host system.
365 <h2><a name="bugs">I think I found a bug in uClibc! What should I do?</h2>
368 If you find a problem with uClibc, please submit a detailed bug report to
369 the uClibc mailing list at <a href="mailto:uclibc@mail.uclibc.org">
370 uclibc@mail.uclibc.org</a>. Please do not send private email to Erik
371 (the maintainer of uClibc) asking for private help unless you are planning
372 on paying for consulting services. When we answer questions on the uClibc
373 mailing list, it helps everyone, while private answers help only you...
375 A well-written bug report should include an example that demonstrates the
376 problem behaviors and enables anyone else to duplicate the bug on their own
377 machine. For larger applications where it may prove difficult to provide
378 an example application, we recommend that you use a tool such as gdb,
379 strace, ltrace, and or valgrind to create a logfile showing the problem
384 <h2><a name="job_control">Why do I keep getting "sh: can't access tty; job control
385 turned off" errors? Why doesn't Control-C work within my shell?</a></h2>
388 This isn't really a uClibc question, but I'll answer it here anyways. Job
389 control will be turned off since your shell can not obtain a controlling
390 terminal. This typically happens when you run your shell on /dev/console.
391 The kernel will not provide a controlling terminal on the /dev/console
392 device. Your should run your shell on a normal tty such as tty1 or ttyS0
393 and everything will work perfectly. If you <em>REALLY</em> want your shell
394 to run on /dev/console, then you can hack your kernel (if you are into that
395 sortof thing) by changing drivers/char/tty_io.c to change the lines where
396 it sets "noctty = 1;" to instead set it to "0". I recommend you instead
397 run your shell on a real console...
402 <h2><a name="autoconf">How do I make autoconf and automake behave?</a></h2>
405 When you are cross-compiling, autoconf and automake are known to behave
406 badly. This is because a large number of configure scripts (such as the
407 one from openssh) try to actually execute applications that were cross
408 compiled for your target system. This is bad, since of course these won't
409 run, and this will also prevent your programs from compiling. You need to
410 complain to the authors of these programs and ask them to fix their broken
416 <h2><a name="ldd">When I run 'ldd' to get a list of the library dependencies
417 for a uClibc binary, ldd segfaults! What should I do?</a></h2>
420 Use the ldd that is built by uClibc, not your system's one. You can build
421 uClibc'd ldd for your host system by going into the uClibc/utils/ directory
422 in the uClibc source and running 'make ldd.host'.
425 When your system's ldd looks for library dependencies, it actually _runs_
426 that program. This works fine -- usually. It generally will not work at
427 all when you have been cross compiling (which is why ldd segfaults). The
428 ldd program created by uClibc is cross platform and doesn't mind at all if
429 it cannot execute the target program. If you use the uClibc version of
430 'ldd', it will do the right thing and produce correct results, even when it
431 is used on cross compiled binaries.
436 <h2><a name="timezones">Why does localtime() return times in UTC even when I have my timezone set?</a></h2>
440 The uClibc time functions get timezone information from the TZ environment
441 variable, as described in the Single Unix Specification Version 3. See
442 <a href="http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html">
443 http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html</a>
444 for details on valid settings of TZ. For some additional examples, read
445 <a href="http://www.uclibc.org/lists/uclibc/2002-August/006261.html">
446 http://www.uclibc.org/lists/uclibc/2002-August/004010.html</a> in the uClibc
447 mailing list archive.
448 You can store the value of TZ in the file '/etc/TZ' and uClibc will then
449 automagically use the specified setting.
454 <h2><a name="history">What is the history of uClibc? Where did it come from?</a></h2>
458 uClibc started off as a fork on the <a
459 href="http://www.cix.co.uk/~mayday/">Linux-8086 C library</a>, which is
460 part of the <a href="http://www.elks.ecs.soton.ac.uk/">elks project</a>.
461 The Linux-8086 C library was, apparently, largely written from scratch but
462 also borrowed code from libc4, glibc, some Atari library code, with bits
463 and pieces from about 20 other places.
467 I had for some time been despairing over the state of C libraries in Linux.
468 GNU libc, the standard, is very poorly suited to embedded systems and has
469 been getting bigger with every release. I spent quite a bit of time
470 looking over the available Open Source C libraries that I knew of, and none
471 of them really impressed me. I felt there was a real vacancy in the
472 embedded Linux ecology. The closest library to what I imagined an embedded
473 C library should be was uClibc. But it had a lot of problems too -- not
474 the least of which was that, traditionally, uClibc required a complete
475 source tree fork in order to support each and every new platform. This
476 resulted in a big mess of twisty versions, all different. I decided to fix
477 it and the result is what you see here.
481 To start with, (with some initial help from <a
482 href="http://www.uclinux.org/developers/">D. Jeff Dionne</a>), I ported
483 uClibc to run on i386. I then grafted in the header files from glibc and
484 cleaned up the resulting breakage. This (plus some additional work) has
485 made it much less dependant on kernel headers, a large departure from its
486 traditional tightly-coupled-to-the-kernel origins. I have written and/or
487 rewritten a number of things that were missing or broken, and sometimes
488 grafted in bits of code from the current glibc and libc5. I have also
489 added a proper configuration system which allows you to easily select your
490 target architecture and enable and disable various features. Many people
491 have helped by testing, contributing ports to new architectures, and adding
492 support for missing features.
496 In particular, around the end of 2000, Manuel Novoa III got involved with
497 uClibc. One of his first contributions was the original gcc wrapper (which
498 has since been removed). Since then, he has written virtually all of the
499 current uClibc stdio, time, string, ctype, locale, and wchar-related code,
500 as well as much of stdlib and various other bits throught the library.
504 These days, uClibc is being developed and enhanced by Erik Andersen
505 and Manuel Novoa III of
506 <a href="http://codepoet-consulting.com/">CodePoet Consulting</a>
507 along with the rest of the embedded Linux community.
513 <h2><a name="demanding">I demand that you to add <favorite feature> right now! How come
514 you don't answer all my questions on the mailing list instantly? I demand
515 that you help me with all of my problems <em>Right Now</em>!</a></h2>
518 You have not paid us a single cent and yet you still have the
519 product of several years of work from Erik and Manuel and
520 many other people. We are not your slaves! We work on uClibc
521 because we find it interesting. If you go off flaming us, we will
528 <h2><a name="helpme">I need help with uClibc! What should I do?</a></h2>
531 If you find that you need help with uClibc, you can ask for help on the
532 uClibc mailing list at uclibc@mail.uclibc.org. In addition to the uClibc
533 mailing list, Erik and Manuel are also known to sometimes hang out on the
534 uClibc IRC channel: #uclibc on irc.freenode.net.
538 <b>Please do not send private email to Erik and/or Manuel asking for
539 private help unless you are planning on paying for consulting services.</b>
540 When we answer questions on the uClibc mailing list, it helps everyone
541 since people with similar problems in the future will be able to get help
542 by searching the mailing list archives. Private help is reserved as a paid
543 service. If you need to use private communication, or if you are serious
544 about getting timely assistance with uClibc, you should seriously consider
545 paying for consulting time.
553 <h2><a name="contracts">I need you to add <favorite feature>! Are the uClibc developers willing to
554 be paid in order to fix bugs or add in <favorite feature>? Are you willing to provide
555 support contracts?</a></h2>
558 Sure! Now you have our attention! What you should do is contact <a
559 href="mailto:andersen@codepoet.org">Erik Andersen</a> of <a
560 href="http://codepoet-consulting.com/">CodePoet Consulting</a> to bid
561 on your project. If Erik is too busy to personally add your feature, there
562 are several other active uClibc contributors who will almost certainly be able
563 to help you out. Erik can contact them and ask them about their availability.
568 <h2><a name="support">I think you guys are great and I want to help support your work!</a></h2>
571 Wow, that would be great! You can click here to help support uClibc and/or request features.
573 <!-- Begin PayPal Logo -->
575 <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
576 <input type="hidden" name="cmd" value="_xclick">
577 <input type="hidden" name="business" value="andersen@codepoet.org">
578 <input type="hidden" name="item_name" value="Support uClibc and/or request features">
579 <input type="hidden" name="image_url" value="https://codepoet-consulting.com/images/codepoet.png">
580 <input type="hidden" name="no_shipping" value="1">
581 <input type="image" src="images/donate.png" name="submit" alt="Make donation using PayPal">
584 <!-- End PayPal Logo -->
586 If you prefer to contact us directly for payments, hardware donations,
587 support requests, etc., you can contact
588 <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> here.
657 <!--#include file="footer.html" -->