FAQ.html 25 KB

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