|
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, 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, than using
glibc may be a better choice...
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!
|
- 12 February 2003, uClibc 0.9.18 Released
CodePoet Consulting is pleased to announce the immediate availability of
uClibc 0.9.18. This is primarily a bug-fix release, as there were a few
directory handling problem that could cause application using uClibc 0.9.17
to either segfault or lose the first character when reading directry names.
Unfortunately, once again, this release is _NOT_ binary compatible with
earlier uClibc releases. I _think this will be the last time (with the
possible exception of some future changes to our locale support...)
As usual, the
Changelog
and source code
for this release are available here.
You might want to download uClibc from the closest
kernel.org mirror site.
Just pick the closest mirror site, and then go to
http://www.XX.kernel.org/pub/linux/libs/uclibc/
to download uClibc, where XX is your two letter country code.
- 12 February 2003, development system updates
The uClibc development system has had a number of problems
fixed, and has been updated for uClibc 0.9.18. The
i386
devel system is updated and ready to download. The
powerpc,
and
arm
development systems are still compiling at the momen, and will be
available as soon as they finish building. Have Fun.
- 25 January 2003, uClibc 0.9.17 Released
CodePoet Consulting is pleased to announce the immediate availability of
uClibc 0.9.17. The biggest piece of news with this release, thanks to
Manuel Novoa's continuing hard work, is that we now have fully standards
compliant locale support (optional of course). The support works nicely,
(though configuring the locales you wish to support is still manual -- a
task for the next release). Full locale data for over 300 locales adds
approximately 250k. The collation data for all supported locales is
roughly 180k. This may seem rather large to some -- but it is much smaller
than the approximately 40 MB needed by Glibc to provide the same data. And
if you don't need it, you can either disable locale support entirely, or
enable a smaller set of locales.
This release also fixes lots and lots of bugs. The arm
architecture support (I am embarrassed to note) was totally broken in the
last release, but is now working as expected. A security problem (a
buffer overflow in getlogin_r) was fixed. And there were architecture
updates across the board (x86, arm, powerpc, cris, h8300, sparc, and mips).
And of course, this release includes the usual pile of bug fixes. Many
thanks for the large number of patches and fixes that were contributed!
Unfortunately, this release is not binary compatible with earlier uClibc
releases. As noted as item 3 here,
uClibc does not (yet) attempt to
ensure binary compatibility across releases. We will eventually do that
(once we reach the "1.0" release) but not yet. A few bugs turned up that
needed to be fixed, and the only good way to fix them was to change some
fundamental data structure sizes. As a result, this release is _NOT_
binary compatible with earlier releases -- you will need to recompile your
applications. The x86, arm, powerpc, and mips architectures (i.e. the
systems Erik has available in his office for testing) have been tested and
are known to work following this change. Other architectures may
need additional updates. Sorry about that, but it had to be done.
As usual, the
Changelog
and source code
for this release are available here.
You might want to download uClibc from the closest
kernel.org mirror site.
Just pick the closest mirror site, and then go to
http://www.XX.kernel.org/pub/linux/libs/uclibc/
to download uClibc, where XX is your two letter country code.
- 25 January 2003, dev system updates, arm image released
A number of additional problems have been fixed and the arm build
is now, finally, compiling and working as expected. As such,
I have updated the
i386 development system image, the
powerpc development system image, and I am also releasing
upon an unsuspecting world the brand new
arm development system image!
Have fun!
All three development system images were compiled and built using the stock
buildroot system. These were also
built using the (about to be announced in a couple on minutes) uClibc
0.9.17 release, so if you want to begin compiling and testing stuff with
uClibc, but you don't feel like spending the _hours_ it takes to download,
configure, and build your own uClibc based development system -- then you
may want to download these and give them a try. They each contain a 100 MB
ext2 filesystem with everything you need to begin compiling your own
applications. I have (at least minimally) tested each of them and verified
that the included gcc and g++ compilers produce working uClibc linked
executables.
Oh, and I have also have updated the uClibc/gcc toolchain builders, so
if you just want a simple uClibc/gcc toolchain,
one of these should work for you.
- 10 January 2003, dev system updates, powerpc image released
A few problems showed up in yesterday's development system release
(adduser was broken, gdb didn't work, libstdc++ shared libs were missing,
etc). So I've updated the
i386 development system image to fix these problems.
Also, the
powerpc development system image has finally finished compiling
and is now released upon an unsuspecting world. Have fun!
- 9 January 2003, uClibc development system released
CodePoet Consulting (i.e. Erik) has been working hard on buildroot recently, and is pleased to
offer a full stand-alone uClibc-only development system. This is an ext2
filesystem for i386 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, valgrind,
busybox, GNU coreutils, and more, this should have pretty much everything
you need to get started building your own applications 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. A powerpc and an arm version are in progress. Expect them
to be released shortly....
The
uClibc development system is an 18MB bzip2 compressed ext2 filesystem,
so be prepared to wait if you are on a slow link. If you wish to have more
space, you can loop mount it and 'cp -a' the contents to their own
partition, or do what I did... WARNING, the following can be very
dangerous. Please be sure you know what you are doing before trying this.
I am not responsible if you lose all your important data.I had a spare
hard drive (in my case /dev/hdg but you'll want to adapt this to your own
needs), so I partitioned it with a single ext2 partition filling the drive
(in my case /dev/hdg1). Then I ran:
bzcat root_fs-i386.bz2 | dd of=/dev/hdg1
e2fsck -f /dev/hdg1
resize2fs -p /dev/hdg1
which overwrote everything on /dev/hdg with the new uClibc devel system,
and then expanded the filesystem with the uClibc devel system till it
filled the whole drive.
- 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 feature
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).
|
|
|
