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
|
<!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 arm, i386, m68k, mipsel, powerpc, sh,
sparc, and v850.
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
Does uClibc support shared libraries?
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
Yes. uClibc has shared library support on x86, arm, and powerpc.
Shared Libraries are _not_ currently supported on MMU-less systems.
<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 you uClibc is simply the microcontroller C library.
This is because uClibc was originaly created to support uClinux, a port of
Linux for MMU-less microcontrollers such as the Dragonball, Coldfire, and
ARM7TDMI. For simplicity, it is pronounced "yew-see-lib-see".
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
Can I use it on my desktop x86 system?
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
Sure! In fact, this can be very nice during development. By using it 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>
Why are you doing this? Whats wrong with glibc?
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
The inital reason, was that glibc does not support MMU-less systems. But
also because uClibc is so much smaller then the GNU C library. The GNU C
library has a different set of goals then uClibc. The GNU C library is a
great piece of software. It complies with just about every standard ever
created, and runs on just about every operating system as well -- 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 has been designed from the ground up to be a C library for embedded
Linux. We don't need to worry about whether we support MS-DOS, or Cygwin,
or any other system. This lets us cut out lots of complexity, and very
carefully optimize for Linux. By very careful design, we can also take a
few shortcuts. For example, glibc contains an implementation of the
wordexp() function, in compliance with the Single Unix Specificaion,
version 2. Well, standards are important. But so is pragmatism. The
wordexp function is huge, and yet I am not aware of even one Linux
application that uses wordexp. So uClibc doesn't provide wordexp(). There
are many similar examples.
Glibc is a general purpose C library, and so as policy things are optimized
for speed. Most of uClibc's routines have been very carefuly written to
optimize them for size instead of speed.
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, but 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 system, and you are tight on space, then
using uClibc instead if glibc should allow you to use your storage for
other things.
If you are trying to build a ultra fast fileserver for your company that
has 12 Terabytes of storage, then you probably want to use glibc...
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
I want to create a closed source commercial application and I want to
protect my intellectual property. If I use uClibc, don't I have to
release all my source code for free?
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
No, you do not need to give away your source code just because you use
uClibc and/or run on Linux.
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
I want to create a closed source commercial application using uClibc.
Is that legal?
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
Yes. uClibc is licensed under the LGPL, just like GNU libc. If you are
using uClibc as a shared library, then your closed source application is
100% legal. Please consider sharing some of the money you make. :-)
If you are staticly linking your closed source commercial application with
uClibc, then you must take additional steps to comply with the uClibc
license. You can sell your application as usual, but you must also make
your closed source application available to your customers as an object
file which can then be linked with updated versions of uClibc. This will
(in theory) allow your customers to later link with updated versions of
uClibc. 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>
How do I compile stuff?
</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 architecture) and it will automagically
make your program link against uClibc.
<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_.
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
When I run 'ldd' to get a list of the library dependancies for a uClibc
binary, ldd segfault! Or it runs my application? Anyways, it doesn't
work! 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 the library dependancies, it actually tries to
_execute_ that program. This works fine -- usually. I doesn't work at all
when you are cross compiling (thats why ldd segfaults). The ldd program
created by uClibc is cross platform and doesn't actually try to run the
target program like your system one does, so it should do the right thing,
and won't segfault, even when you are cross compiling.
<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">
This 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 it just
gets bigger with every release). I spent quite a bit of time looking over the
other 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 that 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, resulting 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.
<p>
To start with, (with some initial help from <a
href="http://www.uclinux.org/developers/index.html">D. Jeff Dionne</a>), I
ported it to run on x86. 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 independant 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>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
I need you to add <favorite feature> now! How come you don't answer all my
questions on the mailing list withing 5 minutes? I demand that you help me <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
over year and a half of work from Erik and Manuel and lots of other people.
How dare you treat us that way! 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 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 may 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 (we have a credit card machine so
you can avoid online 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">
</TD></TR>
</TABLE>
</P>
<a href="http://uclibc.org/">Well then, click here to return to the uClibc home page.</a>
<!-- 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>
|
