Due primarily to the stdio changes, this release is NOT binary compatible with uClibc 0.9.26 or any earlier release, so be prepared to recompile your software if you are still using an old version of uClibc. Sorry for the pain...

Updated uClibc development systems using uClibc 0.9.27, along with the uClibc buildroot and source code used to compile these development systems, have also been released and are available from the uclibc.org downloads area.

As usual, the Changelog, detailed changelog, and source code for this release are available here.

This release remains binary compatible with uClibc 0.9.21-25, as long as you take care to avoid any configuraton changes that will break things. Please be aware we will break binary compatibilty in the upcoming 0.9.27 release to implement a few necessary changes we have been postponing. That will hopefully be the last ABI change before we freeze the ABI for the upcoming 1.0.x stable uClibc series.

As usual, the Changelog, detailed changelog, and source code for this release are available here.

Please be aware we will break binary compatibilty in the upcoming 0.9.26 release to implement a few changes we have been postponing. That will hopefully be the last ABI change before we freeze the ABI for the upcoming 1.0.x stable uClibc series.

As usual, the Changelog, detailed changelog, and source code for this release are available here.

This release continues to be binary compatible with uClibc 0.9.21 to 0.9.23 -- as long as you pick compatible configuration options. The next release will not be binary compatible. We've been saving up a few needed changes that will be going into the next release, so while you will not need to recompile all your applications and libraries just yet, keep in mind we will have a flag day soon...

As usual, the Changelog, detailed changelog, and source code for this release are available here.

This release continues to be binary compatible with uClibc 0.9.21 and 0.9.22 -- as long as you pick compatible configuration options. Enabling or disabling things like soft-float, locale, wide char support, or changing cpu optimizations are all good examples of binary incompatible configuration options. If have changed any of those sorts of options (or if you are not sure!) you will need to recompile all your applications and libraries.

As usual, the Changelog, detailed changelog, and source code for this release are available here.

This release is binary compatible with uClibc 0.9.21 -- as long as you pick compatible configuration options. Enabling or disabling things like soft-float, locale, wide char support, or changing cpu optimizations are all good examples of binary incompatible configuration options. If have changed any of those sorts of options (or if you are not sure!) you will need to recompile all your applications and libraries.

Updated uClibc development systems using uClibc 0.9.22 will be made available within a few days. Meanwhile, we invite you to try out uClibc with the latest Linux Test Project test suite (you will need to apply a small patch. And also give the latest Perl and Python test suites a try as well. If you find any bugs in uClibc, PLEASE let us know!

As usual, the Changelog, detailed changelog, and source code for this release are available here.

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.

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.

This release has many small improvements. At this point, most applications that compile and work with glibc will also compile and run with uClibc. Perl and Python even pass all the tests in their test suites.

There is currently one notable exception. Applications that use dlopen() to load libraries that themselves depend on other libraries, may have weak symbols within those depended-upon libraries resolved incorrectly. This problem is currently being worked on. Other than that, everything seems to now be working as expected....

As usual, the Changelog, detailed changelog, and source code for this release are available here.

This is a 150 MB ext2 filesystem that runs natively on the specified architecture. It 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 then chroot into them, you can boot into them 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 the uClibc development systems were created.

This is an ext2 filesystem that runs natively on the specified architecture. It 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 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 then chroot into them, you can boot into them using user-mode Linux, you can even 'dd' them to a spare partition and use resize2fs to make them fill the drive. Whatever works best for you.

Have Fun.

As usual, the Changelog and source code for this release are available here.

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.

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.

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.

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

Erik and Manuel have been working on a document describing some of the differences between uClibc and glibc. It's not yet 100% complete, and it hasn't been nicely formatted yet. But it contains a lot of helpful information and is worth a look.

And finally, the the old uClibc configuration system has been completely removed (and there was much rejoicing). It was replaced with an entirely new system based on LinuxKernelConf, which has since been included into Linux 2.5.45, so it looks like Erik made the right choice. Of course, those who have existing build systems using uClibc will need to make a few changes... We think the change is worth it.

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.

Updated gcc-3.2 and gcc-2.95 toolchains will be released shortly.

This toolchain should make it easy for anyone to build uClibc based applications. Source code can be downloaded here. Be aware that much of the needed source code will actually be downloaded on when you compile the toolchains. To build a toolchain, simply grab the source, edit the Makefile to select where you would like the toolchain installed, run 'make', and then go watch TV, eat dinner, or visit with your friends while it compiles. It takes about 15 minutes for Erik to compile the gcc-3.2 toolchain (w/C++ support) on his Athlon XP 1600 (not counting the time it takes to download source code).

The Changelog and source code for this release are available here.

Have fun!

The Changelog and source code for this release are available here.

Have fun!

This toolchain should make it easy for anyone to build uClibc based applications. Source code can be downloaded here. Be aware that much of the needed source code will actually be downloaded on demand when you compile things. To build the toolchain, simply grab the source, edit the Makefile to select where you would like the toolchain installed, run 'make', and then go watch TV, eat dinner, or visit with your friends while it compiles. It takes about 15 minutes for Erik to compile the gcc-3.1.1 toolchain (w/C++ support) on his Athlon XP 1600 (not counting the time it takes to download source code). Your results may vary...

This release adds native shared library support for the Hitachi SuperH architecture, thanks to Stefan Allius and Edie C. Dost. A new mmap based malloc was implemented by Miles Bader. This is much smarter than the old "malloc-simple" and is now the default for mmu-less systems, where it should greatly help reduce memory fragmentation and wastage. In addition to these larger items, there has been a lot of work done to make uClibc a cleaner, more capable, library. Most applications now compile and run without any trouble.

The Changelog and source code for this release are available here.

Have fun!

These toolchains should make it easy to anyone to build uClibc based applications. Source code can be downloaded here. Be aware that much of the needed source code will actually be downloaded on demand when you compile things. To build the toolchain, simply grab the source, edit the Makefile to select where you would like the toolchain installed, run 'make', and then go watch TV, eat dinner, or visit with your friends while it compiles. It takes about 15 minutes for Erik to compile the gcc-3.1 toolchain (w/C++ support) on his Athlon XP 1600 (not counting the time it takes to download source code). Your results may vary...

The Changelog and source code for this release are available here.

The Changelog and source code for this release are available here.

To build the toolchain, simply grab the source, edit the Makefile to select where you would like the toolchain installed. Then run 'make' and wait for it to compile. If you do not have a copy of uClibc already, it will download the latest daily snapshot.

To make things more interesting, the release also adds support for C++ constructors and destructors. To make it easy to use uClibc when developing C++ applications, this release also provides a wrapper for the GNU C++ compiler. Of course, for more complex C++ applications, such as those using iostreams, a standard C++ library (libstdc++) is required. A native GNU toolchain (binutils/gcc) that provides libstdc++ linked with uClibc 0.9.10 will be released in the next couple of days, so stay tuned.

The Changelog and Source code for this release are available here.

The Changelog and Source code for this release are available here.

One final bit on news -- as some of you may have noticed, uclibc.org has been a bit overloaded and somewhat slow recently. The server should be getting colocated tomorrow, which will eliminate the speed problem. During the move, there may be some temporary disruption of service...

Have Fun!

The source code for this release is available here.

I also finished up fixing large file support (just enable DOLFS in your Config file to enable it) and it is working just great, and greatly increases the number of glibc applications that will work "out-of-the-tarball" without needing any changes.