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
|
This is a collection of some of the frequently asked question
about uClibc. Some of the questions even have answers. If you
have additions to this FAQ document, I'd love to add them,
-Erik
Q: Why is it called uClibc?
The letter 'u' is short for the greek letter "mu". "Mu" stands for
"micro", and the "C" is for "controller". uClibc was originaly created to
support uClinux, a port of Linux for MMU-less microcontrollers such as the
Dragonball, Coldfire, and ARM7TDMI.
Q: Can I use it on my desktop x86 system?
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 on your target system.
Q: Why are you doing this? Whats wrong with glibc?
The inital reason, is that glibc does not support MMU-les systems. But
additionaly, 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
Q: So uClibc is smaller then glibc? Doesn't that mean it completely sucks?
How could it be smaller and not suck?
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 make a
few shotcuts. 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 adds almost 100k to glibc, and yet I am not aware of even
one Linux application that uses wordexp. So uClibc doesn't have wordexp().
Glibc is a general purpose C library, and so as policy things are optimized
for speed. uClibc has a large number of routines that have been very
carefuly written to optimize for size instead of speed.
The end result is a C library that will compile just about everything you
throw at it, thet looks like glibc to application programs when you
compile, and is many times smaller.
Q: Why should I use uClibc?
I don't know if you should use uClibc or not. It depends on your goals.
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...
Q: 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 my source code?
No, you do not need to give away your source code just because you use
uClibc and/or run on Linux.
Q: I want to create a closed source commercial application using uClibc.
Is that legal?
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.
Q: How do I compile stuff?
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.
Q: How do I make autoconf and automake behave?
First run
export PATH=/usr/i386-linux-uclibc/bin:$PATH
(or similar adjusted for your target architecture) then run you can simply
run autoconf/automake and it should _just work_.
Q: 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?
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.
Q: 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
Right Now!
You have not paid me a single cent and yet you still have the product of
over year and a half of my work, and lots of work from other people. How
dare you treat me that way! I work on uClibc because I find it
interesting. If you go off flaming me, I will ignore you.
Q: 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?
Sure! Now you have our attention! What you should do is contact
Erik Andersen of CodePoet Consulting to bid on your project. If Erik
is too busy to personally add your feature
Q: I think you guys are great and I want to help support your work!
Wow, that would be great! You can visit
http://paypal.com/
click on "Send Money" and donate to andersen@codepoet.org
I hope that was helpful... If you have and comment, corrections, insults,
suggestions, or bribes, email me at andersen@codepoet.org.
-Erik
--
Erik B. Andersen
andersen@codepoet.org
http://codepoet-consulting.com/
|
