OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [linux/] [uClibc/] [docs/] [uclibc.org/] [FAQ.html] - Blame information for rev 1765

Details | Compare with Previous | View Log

Line No. Rev Author Line
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 &lt;favorite feature&gt; 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 &lt;favorite feature&gt;!  Are the uClibc developers willing to
36
            be paid in order to fix bugs or add in &lt;favorite feature&gt;?  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 &lt;favorite feature&gt; 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 &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
 
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
 

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.