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