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