FAQ.html 19 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510
  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
  2. <HTML>
  3. <HEAD>
  4. <TITLE>uClibc FAQ-- a C library for embedded systems</TITLE>
  5. </HEAD>
  6. <body text="#000000" alink="#660000" link="#660000" bgcolor="#dee2de" vlink="#660000">
  7. <basefont face="lucida, helvetica, arial" size="3">
  8. <CENTER>
  9. <p>
  10. <TABLE BORDER=0 CELLSPACING=1 CELLPADDING=2>
  11. <TR>
  12. <td bgcolor="#000000">
  13. <FONT FACE="lucida, helvetica" COLOR="#ccccc0">
  14. <B>µ&nbsp;C&nbsp;l&nbsp;i&nbsp;b&nbsp;c</B>
  15. </FONT>
  16. </TD>
  17. </TR>
  18. </TABLE>
  19. <p>
  20. <!-- Begin NOT Working List -->
  21. <TABLE WIDTH=95% CELLSPACING=1 CELLPADDING=4 BORDER=1>
  22. <TR><TD BGCOLOR="#ccccc0" ALIGN=center>
  23. <A NAME="notworking"> <BIG><B>
  24. uClibc Frequently Asked Questions (FAQ)
  25. </font>
  26. </A></B></BIG>
  27. </TD></TR>
  28. <TR><TD BGCOLOR="#eeeee0">
  29. <p>
  30. This is a collection of some of the frequently asked questions
  31. about uClibc. Some of the questions even have answers. If you
  32. have additions to this FAQ document, we would love to add them,
  33. <br>
  34. When you are done, <a href="http://uclibc.org/">you can click here to return
  35. to the uClibc home page.</a>
  36. <p>
  37. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  38. <B>
  39. What platforms does uClibc run on?
  40. </B>
  41. </TD></TR>
  42. <TR><TD BGCOLOR="#eeeee0">
  43. Currently uClibc runs on alpha, ARM, i386, i960, h8300, m68k, mips/mipsel,
  44. PowerPC, SH, SPARC, and v850 processors.
  45. <p>
  46. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  47. <B>
  48. Why is it called uClibc?
  49. </B>
  50. </TD></TR>
  51. <TR><TD BGCOLOR="#eeeee0">
  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
  56. "yew-see-lib-see".
  57. <p>
  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.
  63. <p>
  64. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  65. <B>
  66. Why are you doing this? What's wrong with glibc?
  67. </B>
  68. </TD></TR>
  69. <TR><TD BGCOLOR="#eeeee0">
  70. Initially, the project began since the GNU C library lacks support for
  71. MMU-less systems, and because glibc is very large. The GNU C library is
  72. designed with a very different set of goals then uClibc. The GNU C library
  73. is a great piece of software, make no mistake. It is compliant with just
  74. about every standard ever created, and runs on just about every operating
  75. system and architecture -- no small task! But there is a price to be paid
  76. for that. It is quite a large library, and keeps getting larger with each
  77. release. It does not even pretend to target embedded systems. To quote
  78. from Ulrich Drepper, the maintainer of GNU libc: "...glibc is not the right
  79. thing for [an embedded OS]. It is designed as a native library (as opposed
  80. to embedded). Many functions (e.g., printf) contain functionality which is
  81. not wanted in embedded systems." 24 May 1999
  82. <p>
  83. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  84. <B>
  85. So uClibc is smaller then glibc? Doesn't that mean it completely sucks?
  86. How could it be smaller and not suck?
  87. </B>
  88. </TD></TR>
  89. <TR><TD BGCOLOR="#eeeee0">
  90. uClibc has been designed from the ground up to be a C library for
  91. embedded Linux. We don't need to worry about things like MS-DOS
  92. support, or BeOS, or AmigaOs any other system. This lets us cut out
  93. a lot of complexity and very carefully optimize for Linux. By very
  94. careful design, we can also take a few shortcuts. For example, glibc
  95. contains an implementation of the wordexp() function, in compliance
  96. with the Single Unix Specification, version 3. Well, standards are
  97. important. But so is pragmatism. The wordexp function is huge, yet I
  98. am not aware of even one Linux application that uses it! So uClibc
  99. doesn't provide wordexp(). There are many similar examples. In other
  100. cases, uClibc leaves certain features (such as full C99 Math library
  101. support, IPV6, and RPC support) disabled by default. Those features
  102. can be enabled for people that need them, but are otherwise disabled to
  103. save space.
  104. <p>
  105. Glibc is a general purpose C library, and so as policy things are optimized
  106. for speed. Most of uClibc's routines have been very carefully written to
  107. optimize them for size instead.
  108. <p>
  109. The end result is a C library that will compile just about everything you
  110. throw at it, that looks like glibc to application programs when you
  111. compile, but is many times smaller.
  112. <p>
  113. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  114. <B>
  115. Why should I use uClibc?
  116. </B>
  117. </TD></TR>
  118. <TR><TD BGCOLOR="#eeeee0">
  119. I don't know if you should use uClibc or not. It depends on your needs.
  120. If you are building an embedded Linux system and you are tight on space, then
  121. using uClibc instead if glibc may be a very good idea.
  122. If you are trying to build a huge fileserver for your company that will
  123. have 12 Terabytes of storage, then using glibc may make more sense.
  124. Unless, for example, that 12 Terabytes will be Network Attached Storage
  125. and you plan to burn Linux into the system's firmware...
  126. <p>
  127. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  128. <B>
  129. If I use uClibc, do I have to release all my source code to the world for
  130. free? I want to create a closed source commercial application and I want
  131. to protect my intellectual property.
  132. </B>
  133. </TD></TR>
  134. <TR><TD BGCOLOR="#eeeee0">
  135. No, you do not need to give away your source code just because you use
  136. uClibc and/or run on Linux. uClibc is licensed under the LGPL, just like
  137. GNU libc. Using shared libraries makes complying with the license easy.
  138. If you are using uClibc as a shared library, then your closed source
  139. application is 100% legal. Please consider sharing some of the money you
  140. make with us! :-)
  141. <p>
  142. If you are statically linking your closed source application with
  143. uClibc, then you must take additional steps to comply with the uClibc
  144. license. You may sell your statically linked application as usual, but
  145. you must also make your application available to your customers as an
  146. object file which can later be re-linked against updated versions of
  147. uClibc. This will (in theory) allow your customers to apply uClibc bug
  148. fixes to your application. You do not need to make the application
  149. object file available to everyone, just to those you gave the fully
  150. linked application.
  151. <p>
  152. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  153. <B>
  154. Can I use it on my desktop i386 system?
  155. </B>
  156. </TD></TR>
  157. <TR><TD BGCOLOR="#eeeee0">
  158. Sure! In fact, this can be very nice during development. By
  159. installing uClibc on your development system, you can be sure that
  160. the code you are working on will actually run when you deploy it
  161. your target system.
  162. <p>
  163. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  164. <B>
  165. Does uClibc support shared libraries?
  166. </B>
  167. </TD></TR>
  168. <TR><TD BGCOLOR="#eeeee0">
  169. Yes. uClibc has native shared library support on i386, ARM, mips/mipsel,
  170. SH, CRIS, and PowerPC processors. Other architectures can use shared libraries
  171. but will need to use the GNU libc shared library loader.
  172. <p>
  173. Shared Libraries are not currently supported by uClibc on MMU-less systems.
  174. <a href="http://www.snapgear.com/">SnapGear</a> has implemented
  175. shared library support for MMU-less systems, however, so if you need MMU-less
  176. shared library support they may be able to help.
  177. <p>
  178. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  179. <B>
  180. How do I compile programs with uClibc?
  181. </B>
  182. </TD></TR>
  183. <TR><TD BGCOLOR="#eeeee0">
  184. The easiest way is to use the compiler wrapper built by uClibc. Instead of
  185. using your usual compiler or cross compiler, you can use i386-uclibc-gcc,
  186. (or whatever is appropriate for your target architecture) and your
  187. applications will auto-magically link against uClibc. You can also
  188. build your own native uClibc toolchain. Just download the uClibc toolchain
  189. builder from <a href="http://www.uclibc.org/downloads/toolchain/">
  190. http://www.uclibc.org/downloads/toolchain/</a>, or the uClibc buildroot
  191. system from <a href="http://www.uclibc.org/downloads/buildroot/">
  192. http://www.uclibc.org/downloads/buildroot/</a>, adjust the Makefile
  193. settings to match your target system, and then run 'make'.
  194. <p>
  195. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  196. <B>
  197. Why do I keep getting "sh: can't access tty; job control turned off" errors?
  198. Why doesn't Control-C work within my shell?
  199. </B>
  200. </TD></TR>
  201. <TR><TD BGCOLOR="#eeeee0">
  202. This isn't really a uClibc question, but I'll answer it here anyways. Job
  203. control will be turned off since your shell can not obtain a controlling
  204. terminal. This typically happens when you run your shell on /dev/console.
  205. The kernel will not provide a controlling terminal on the /dev/console
  206. device. Your should run your shell on a normal tty such as tty1 or ttyS0
  207. and everything will work perfectly. If you <em>REALLY</em> want your shell
  208. to run on /dev/console, then you can hack your kernel (if you are into that
  209. sortof thing) by changing drivers/char/tty_io.c to change the lines where
  210. it sets "noctty = 1;" to instead set it to "0". I recommend you instead
  211. run your shell on a real console...
  212. <p>
  213. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  214. <B>
  215. How do I make autoconf and automake behave?
  216. </B>
  217. </TD></TR>
  218. <TR><TD BGCOLOR="#eeeee0">
  219. First run
  220. <pre>export PATH=/usr/i386-linux-uclibc/bin:$PATH</pre>
  221. (or similar adjusted for your target architecture) then run you can simply
  222. run autoconf/automake and it should _just work_. Unfortunately, a large
  223. number of configure scripts (such as the one from openssh) try to execute
  224. test applications using your target C library, even if you are cross-
  225. compiling. This is bad, since it will prevent these programs from compiling.
  226. You need to complain to the authors of these programs and ask them to fix
  227. their broken configure scripts.
  228. <p>
  229. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  230. <B>
  231. When I run 'ldd' to get a list of the library dependencies for a uClibc
  232. binary, ldd segfaults! What should I do?
  233. </B>
  234. </TD></TR>
  235. <TR><TD BGCOLOR="#eeeee0">
  236. Use the ldd that is built by uClibc, not your system's one. When your
  237. system's ldd looks for library dependencies, it actually _runs_ that
  238. program. This works fine -- usually. It generally will not work at all
  239. when you have been cross compiling (which is why ldd segfaults). The ldd
  240. program created by uClibc is cross platform and doesn't even try to run
  241. the target program (like your system one does). So use the uClibc one
  242. and it will do the right thing, and it won't segfault even when you are
  243. cross compiling.
  244. <p>
  245. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  246. <B>
  247. Why does localtime() return times in UTC even when I have my timezone set?
  248. </B>
  249. </TD></TR>
  250. <TR><TD BGCOLOR="#eeeee0">
  251. The uClibc time functions get timezone information from the TZ environment
  252. variable, as described in the Single Unix Specification Version 3. See
  253. <a href="http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html">
  254. http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html</a>
  255. for details on valid settings of TZ. For some additional examples, read
  256. <a href="http://www.uclibc.org/lists/uclibc/2002-August/006261.html">
  257. http://www.uclibc.org/lists/uclibc/2002-August/006261.html</a> in the uClibc
  258. mailing list archive.
  259. You can store the value of TZ in the file '/etc/TZ' and uClibc will then
  260. automagically use the specified setting.
  261. <p>
  262. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  263. <B>
  264. What is the history of uClibc? Where did it come from?
  265. </B>
  266. </TD></TR>
  267. <TR><TD BGCOLOR="#eeeee0">
  268. The history and origin of uClibc is long and twisty.
  269. In the beginning, there was <a href="http://www.gnu.org/software/libc/libc.html">GNU libc</a>. Then, libc4
  270. (which later became linux libc 5) forked from GNU libc version 1.07.4, with
  271. additions from 4.4BSD, in order to support Linux. Later, the <a
  272. href="http://www.cix.co.uk/~mayday/">Linux-8086 C library</a>, which is part of
  273. the <a href="http://www.elks.ecs.soton.ac.uk/">elks project</a>, was created,
  274. which was, apparently, largely written from scratch but also borrowed code from
  275. libc4, glibc, some Atari library code, with bits and pieces from about 20 other
  276. places. Then uClibc forked off from the Linux-8086 C library in order to run
  277. on <a href="http://www.uclinux.org">µClinux</a>.
  278. <p>
  279. I had for some time been despairing over the state of C libraries in Linux.
  280. GNU libc, the standard, is very poorly suited to embedded systems and
  281. has been getting bigger with every release. I spent quite a bit of time looking over the
  282. available Open Source C libraries that I knew of (listed below), and none of them really
  283. impressed me. I felt there was a real vacancy in the embedded Linux ecology.
  284. The closest library to what I imagined an embedded C library should be was
  285. uClibc. But it had a lot of problems too -- not the least of which was that,
  286. traditionally, uClibc had a complete source tree fork in order to support each
  287. and every new platform. This resulted in a big mess of twisty versions, all
  288. different. I decided to fix it and the result is what you see here.
  289. My source tree has now become the official uClibc source tree and it now lives
  290. on cvs.uclinux.org and www.uclibc.org.
  291. <p>
  292. To start with, (with some initial help from <a
  293. href="http://www.uclinux.org/developers/">D. Jeff Dionne</a>), I
  294. ported it to run on i386. I then grafted in the header files from glibc 2.1.3
  295. and cleaned up the resulting breakage. This (plus some additional work) has
  296. made it almost completely independent of kernel headers, a large departure from
  297. its traditional tightly-coupled-to-the-kernel origins. I have written and/or
  298. rewritten a number of things that were missing or broken, and sometimes grafted
  299. in bits of code from the current glibc and libc5. I have also built a proper
  300. platform abstraction layer, so now you can simply edit the file "Config" and
  301. use that to decide which architecture you will be compiling for, and whether or
  302. not your target has an MMU, and FPU, etc. I have also added a test suite,
  303. which, though incomplete, is a good start. Several people have helped by
  304. contributing ports to new architectures, and a lot of work has been done on
  305. adding support for missing features.
  306. <p>
  307. These days, uClibc is being developed and enhanced by Erik Andersen of
  308. <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> along
  309. with the rest of the embedded Linux community.
  310. <p>
  311. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  312. <B>
  313. I demand that you to add &lt;favorite feature&gt; right now! How come
  314. you don't answer all my questions on the mailing list instantly? I demand
  315. that you help me with all of my problems <em>Right Now</em>!
  316. </B>
  317. </TD></TR>
  318. <TR><TD BGCOLOR="#eeeee0">
  319. You have not paid us a single cent and yet you still have the
  320. product of nearly two years of work from Erik and Manuel and
  321. many other people. We are not your slaves! We work on uClibc
  322. because we find it interesting. If you go off flaming us, we will
  323. ignore you.
  324. <p>
  325. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  326. <B>
  327. I need you to add &lt;favorite feature&gt;! Are the uClibc developers willing to
  328. be paid in order to fix bugs or add in &lt;favorite feature&gt;? Are you willing to provide
  329. support contracts?
  330. </B>
  331. </TD></TR>
  332. <TR><TD BGCOLOR="#eeeee0">
  333. Sure! Now you have our attention! What you should do is contact <a
  334. href="mailto:andersen@codepoet.org">Erik Andersen</a> of <a
  335. href="http://codepoet-consulting.com/">CodePoet Consulting</a> to bid
  336. on your project. If Erik is too busy to personally add your feature, there
  337. are several other active uClibc contributors who will almost certainly be able
  338. to help you out. Erik can contact them and ask them about their availability.
  339. <p>
  340. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  341. <B>
  342. I think you guys are great and I want to help support your work!
  343. </B>
  344. </TD></TR>
  345. <TR><TD BGCOLOR="#eeeee0">
  346. Wow, that would be great! You can click here to help support uClibc and/or request features.
  347. <!-- Begin PayPal Logo -->
  348. <center>
  349. <form action="https://www.paypal.com/cgi-bin/webscr" method="post">
  350. <input type="hidden" name="cmd" value="_xclick">
  351. <input type="hidden" name="business" value="andersen@codepoet.org">
  352. <input type="hidden" name="item_name" value="Support uClibc and/or request features">
  353. <input type="hidden" name="image_url" value="https://codepoet-consulting.com/images/codepoet.png">
  354. <input type="hidden" name="no_shipping" value="1">
  355. <input type="image" src="images/donate.png" border="0" name="submit" alt="Make donation using PayPal">
  356. </form>
  357. </center>
  358. <!-- End PayPal Logo -->
  359. If you prefer to contact us directly for payments, hardware donations,
  360. support requests, etc., you can contact
  361. <a href="http://codepoet-consulting.com/">CodePoet Consulting</a> here.
  362. <p>
  363. <TR><TD BGCOLOR="#ccccc0" ALIGN=left>
  364. <B>
  365. Ok, I'm done reading all these questions.
  366. </B>
  367. </TD></TR>
  368. <TR><TD BGCOLOR="#eeeee0">
  369. <a href="http://uclibc.org/">Well then, click here to return to the uClibc home page.</a>
  370. <!-- End things -->
  371. </TD></TR>
  372. </TABLE>
  373. </P>
  374. <!-- Footer -->
  375. <HR>
  376. <TABLE WIDTH="100%">
  377. <TR>
  378. <TD>
  379. <font size="-1" face="arial, helvetica, sans-serif">
  380. Mail all comments, insults, suggestions and bribes to
  381. <a href="mailto:andersen@codepoet.org">Erik Andersen</a><BR>
  382. </font>
  383. </TD>
  384. <TD>
  385. <a href="http://www.vim.org"><img border=0 width=90 height=36
  386. src="images/written.in.vi.png"
  387. alt="This site created with the vi editor"></a>
  388. </TD>
  389. <TD>
  390. <a href="http://www.gimp.org/"><img border=0 width=90 height=36
  391. src="images/gfx_by_gimp.png" alt="Graphics by GIMP"></a>
  392. </TD>
  393. <TD>
  394. <a href="http://www.linuxtoday.com"><img width=90 height=36
  395. src="images/ltbutton2.png" alt="Linux Today"></a>
  396. </TD>
  397. <TD>
  398. <p><a href="http://slashdot.org"><img width=90 height=36
  399. src="images/sdsmall.png" alt="Slashdot"></a>
  400. </TD>
  401. <TD>
  402. <a href="http://freshmeat.net"><img width=90 height=36
  403. src="images/fm.mini.png" alt="Freshmeat"></a>
  404. </TD>
  405. </TR>
  406. </TABLE>
  407. </CENTER>
  408. </BODY>
  409. </HTML>