uClibc (aka µClibc/pronounced
yew-see-lib-see) is a C library for developing embedded Linux systems.
It is much smaller than the
GNU C Library,
but nearly all applications supported by glibc also work perfectly with
uClibc. Porting applications from glibc to uClibc typically involves
just recompiling the source code. uClibc even supports shared libraries
and threading. It currently runs on standard Linux
and MMU-less (also known as µClinux)
systems with support for alpha, ARM, cris, i386, i960, h8300, m68k, mips/mipsel,
PowerPC, SH, SPARC, and v850 processors.
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...
uClibc is maintained by
Erik Andersen
and is licensed under the
GNU LIBRARY GENERAL PUBLIC LICENSE
. This license allows you to make closed source commercial applications using
uClibc (Please consider sharing some of the money you make ;-). You do not need
to give away all your source code just because you use uClibc and/or run on Linux.
Mailing List Information
uClibc has a mailing list.
To subscribe, go and visit
this page.
Frequently Asked Questions
Before asking questions on the uClibc mailing list,
you might want to take a look at the
list of Frequently Asked Questions
or
you might want to search the mailing list archives...
Working Applications List
These days, pretty much everything compiles with uClibc. This
is a list of applications that are known
to work just fine with uClibc. Since most applications work just
fine with uClibc, we are especially interested in knowing about any
applications that either do not compile or do not work
properly with uClibc. Submissions are welcome!
|
- 30 September 2003, dev systems updated to uClibc 0.9.21+
The uClibc development systems for
i386,
powerpc,
arm,
mips,
have been updated to uClibc 0.9.21 (plus all the CVS updates up to
today). Several problems have been fixed up,
gcc has been updated to version 3.3.1, binutils was updated to 2.14.90.0.6, and
tada everything finally works for cross compiling. These were
all cross compiled (which really makes things faster since the older
mipsel releases used to take 2 days to build!)
These are ~100 MB ext2 filesystems that run natively on the specified
architecture. They contains all the development software you need to build
your own uClibc applications, including bash, coreutils, findutils,
diffutils, patch, sed, ed, flex, bison, file, gawk, tar, grep gdb, strace,
make, gcc, g++, autoconf, automake, ncurses, zlib, openssl, openssh perl,
and more. And of course, everything is dynamically linked against uClibc.
By using a uClibc only system, you can avoid all the painful
cross-configuration problems that have made using uClibc somewhat painful
in the past. If you want to quickly get started with testing or using
uClibc you should give these images a try. You can loop mount and them
you can chroot into them, you can boot into with using user-mode Linux,
and you can even 'dd' them to a spare partition and use resize2fs to make
them fill the drive. Whatever works for you.
If you would like to build your own custom uClibc system, you can
use buildroot, which is
how these uClibc development systems were created.
- 9 September 2003, uClibc 0.9.21 Released
CodePoet Consulting is pleased to announce the immediate availability of
uClibc 0.9.21. This release has been brewing for several months now, and
provides quite a lot of additional functionality and quite a few bug fixes
as well. Many people will be pleased that this release fixes the
"dlopen()'ing libraries that depend on libraries" problem.
The biggest thing in this release (and I do mean that literally) is that
uClibc now has full ANSI/ISO C99 locale support. Well, except for
wcsftime() and collating items in regex, which are not done yet. Adding
support for the default set of locales (169 UTF-8 locales and 144 locales
using other codesets) will enlarge uClibc by around 300k. Still, if you
need locale support, that is still much better than the roughly 30MB the
comparable set of locale date occupies with glibc. And you can of course
reduce the 300k by reducing the number of supported locales.
As usual, this release has many improvements, both large and small. At
this point, most applications that compile and work with glibc will also
compile and run with uClibc. Both Perl and Python pass all the tests in
their test suites (both with and without locale support enabled). We
invite you to grab a copy of the latest Linux Test Project test suite and
give uClibc some abuse. We are not yet perfect, but we are getting pretty
darn close.
This release is not binary compatible with earlier releases. Depending on
your configuration, you may actually still be binary compatible, but it
would be a good idea to recompile your applications when moving to the
uClibc 0.9.21 release. We are sorry about that, but we have never promised
to provide binary compatibility until we hit version 1.0. And even then,
if you change your uClibc configuration, you still still generally need to
recompile...
As usual, the
Changelog,
detailed changelog,
and source code for this release
are available here.
Updated uClibc development systems using uClibc 0.9.21 will be made
available within a few days.
- Old News
Click here to read older news.
|
Please visit our sponsors and thank them for their support! They have
provided money, equipment, bandwidth, etc. Next time you need help with a
project, consider these fine companies! Several individuals have also
contributed (If you have contributed and would like your name added here,
just email Erik and let him know).
Do you like uClibc? Do you need support? Do you need some features
added? Then why not help out? We are happy to accept donations
(such as bandwidth, mirrors sites, and hardware for the various
architectures). We can also provide support contracts, and implement
funded feature requests. To contribute, you can either click on the
Donate image to donate using PayPal, or you can contact Erik at
CodePoet Consulting
(we have a credit card machine so you can avoid PayPal if you wish).
|
|
|