You can find Erik's uwoody distribution uwoody distribution here. As a result, we are now releasing uClibc 0. This release remains binary compatible with uClibc 0.
Please be aware we will break binary compatibilty in the upcoming 0. This contains many bug fixes and cleanups, and is recommended for anyone using uClibc. We were planning to break binary compatibilty in this release, but decided to hold those changes so we could push out a bugfix release. The powerpc dev system mostly works, but there are still some problems with the shared library loader that have not yet been resolved. This contains various minor updates and fixes for a few silly configuration problems.
Arm users should notice a speed increase since some arm optimized string functions have been added. And several bugs have been fixed. This release continues to be binary compatible with uClibc 0. 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 Of course, we are somewhat less than pleased that there were configuration problems in the previous release that made such it necessary to release.
And Erik has built Debian stable woody for x86 with uClibc and it runs great. 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! This release has been cooking for a couple of months now and is looking quite solid. We have done quite a lot of testing with this release and things are looking good. Expect that to be released in the next few days. This release is binary compatible with uClibc 0. 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. Several problems have been fixed up, gcc has been updated to version 3. These were all cross compiled which really makes things faster since the older mipsel releases used to take 2 days to build! 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. 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. Well, except for wcsftime and collating items in regex, which are not done yet. Adding support for the default set of locales UTF-8 locales and locales using other codesets will enlarge uClibc by around k. 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 k 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. We are sorry about that, but we have never promised to provide binary compatibility until we hit version 1. And even then, if you change your uClibc configuration, you still still generally need to recompile This is primarily a bug-fix release. This release remains binary compatible with 0. This release has many small improvements.
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 This is a MB ext2 filesystem that runs natively on the specified architecture. 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.
If you would like to build your own custom uClibc system, you can use buildroot , which is how the uClibc development systems were created. Several smaller problems have also been fixed up. This is an ext2 filesystem that runs natively on the specified architecture.
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. This is once again primarily a bug-fix release. Several critical problems with system calls were fixed, the pthreads library was improved, debugging of applications using uClibc's pthreads library is now possible requires gdb 5.
This release retains binary compatibility with uClibc 0. Updated development system images compiled with uClibc 0. As usual, the Changelog and source code for this release are available here. The i and powerpc , and arm devel systems are updated and ready to download and use. This is primarily a bug-fix release, as there were a few directory handling problem that could cause application using uClibc 0. You might want to download uClibc from the closest kernel.
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 locales adds approximately k. The collation data for all supported locales is roughly k. 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.
And there were architecture updates across the board x86, arm, powerpc, cris, h, 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. 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. The x86, arm, powerpc, and mips architectures i.
Other architectures may need additional updates. Sorry about that, but it had to be done. As such, I have updated the i 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. They each contain a MB ext2 filesystem with everything you need to begin compiling your own applications.
So I've updated the i 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. 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 i containing all the development software you need to build your own uClibc applications.
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 Please be sure you know what you are doing before trying this. I am not responsible if you lose all your important data. This release adds full support including a native shared library loader for the CRIS architecture, contributed by Tobias Anderberg.
Stefan Allius contributed a number of patches to fix the initialization order for shared library global constructors and destructors as well as a large number of SuperH fixes and cleanups. RedHat 8. Thanks to Christian Michon, uClibc no longer requires perl to compile. Steven J. Hill fixed dlopen for mips. Several problems with pty and tty handling were fixed. Manuel is still hard at work on bringing full locale support optional of course to uClibc.
Erik and Manuel have been working on a document describing some of the differences between uClibc and glibc. 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. Of course, those who have existing build systems using uClibc will need to make a few changes We think the change is worth it. Updated gcc Erik has released updated gcc These toolchains build real gcc cross compilers i. The new gcc The gcc 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 This release fixes a number of problems that turned up since the last release. The good news is that uClibc now passes all tests in the perl 5. So without any further ado While you are waiting, buildroot will download all the needed source code and then compile things up for you.
You should now have a shiny new toolchain, and maybe even a shiny new uClibc based root filesystem or development system, depending on the options you selected. If you want to be really lazy and start using uClibc right away without needing to compile your own toolchain or anything, you can grab a pre-compiled uClibc development system.
These are currently available for arm , armeb , i , mips , mipsel , powerpc , and sh4. Note: that the images mentioned above are old and ment for demonstration purposes only. Each of these uClibc development systems was created using buildroot , specifically, buildroot These development systems should provide pretty much everything you need to get started building your own applications with uClibc.
Once you download one of these systems, you can then boot into it, loop mount it, dd it to a spare drive and use a tool such as resize2fs to make it fill a partition
0コメント