Tag: uclibc

uClibc 0.9.32 released, with NPTL support

A little bit more than one year after 0.9.31, the uClibc project has recently released a new version of the famous C library, uClibc 0.9.32. For the record, uClibc is an alternative standard C library for embedded Linux systems, which features a smaller size than the usual glibc or eglibc, a high-level of configurability and support for non-MMU architectures. uClibc usage is mandatory on non-MMU architectures running a Linux kernel since the traditional glibc or eglibc do not support non-MMU architectures. On architectures with MMU, uClibc may also be interesting for its reduced size, and has been used in a large number of systems over the last years.

The 0.9.32 release brings one major new feature : the support of the Native Posix Threads Library for the most common architectures (ARM, MIPS, PowerPC, x86, x86_64, SuperH and SuperH 64). NPTL is a different way of implementing the pthread userspace API than the one previously used in Linux, called LinuxThreads. The kernel mechanisms needed to implement NPTL have been added in 2.6 and support in glibc has been added a long time ago. uClibc was lagging behind in this area, and the new release fills this gap. This feature does not bring any visible API change, but completely changes the internal implementation of the threading mechanism, with better performance and a behavior that is more similar to the one we have on glibc based hosts. For more details about the differences about NPTL and LinuxThreads, one can check Ulrich Drepper and Ingo Molnar’s paper on this topic: NPTL Design paper.

Another new feature of the 0.9.32 release is support for the C6x architecture, which is a DSP architecture from Texas Instruments, capable of running a Linux kernel (see http://linux-c6x.org). Having upstream support in uClibc allows this architecture to benefit from a nice standard C library.

Buildroot gains better support for external toolchains

Buildroot logoBuildroot is a tool that I’ve already covered in a previous blog post. To me, its main purpose is to build the root filesystem for an embedded Linux system, with all the necessary applications and libraries. It automates the tedious process of cross-compiling and integrating all the free software components in an embedded system.

In addition to root filesystem generation, Buildroot is also known for its ability to generate a uClibc-based cross-compilation toolchain. Buildroot used to be for quite some time the only way to generate a toolchain based on this size-effective C library, but it is no longer the case with Crosstool-NG supporting glibc, uClibc and eglibc.

However, I’ve personaly never been really satisfied with uClibc generation of cross-compiling toolchains:

  • It mixes the process of the cross-compilingn toolchain generation with the process of root filesystem generation, which are, in my opinion, two very different processes. Once your toolchain is generated, you generally don’t touch it, but regenerate your root filesystem dozens or hundred of times until all your components are here and properly integrated.
  • The attention paid to toolchain generation in the Buildroot project itself is relatively small, while other projects like Crosstool-NG or vendors like Codesourcery, are specifically dedicated to providing toolchains. The fact that, for example, uClibc is the only C library supported is one example of this.
  • It might necessary, for various reasons, make sense to use an already existing toolchain.

Support for the usage of external toolchains has already been present in Buildroot for a long time, but wasn’t developed enough to be easily usable. Months ago, I’ve started to improve the situation (here, here, here and here), and last week, two other patches have been integrated.

  • The first patch, visible here removes the ugly configuration option that allows to configure the set of libraries that must be copied to the target filesystem, and replaces it with a nice selection of the C libary type: uClibc or glibc. It makes it clear that generating Linux system with the glibc library is possible with Buildroot, even if Buildroot has often been advertised as a uClibc only tool.
  • The second patch, visible here adds checks for the conformity of Buildroot configuration versus the C library configuration. There are configuration options in Buildroot that must tell whether the C library supports IPv6, supports RPC, supports locale, supports large file, etc. These options must be set in the configuration interface according to the C library configuration, because some userspace packages depend on them. The added checks verify that the value set to these options match the configuration of your C library

So, now, external toolchains are a little bit easier to use with Buildroot, and your own vendor toolchain, Codesourcery toolchains or any other toolchain can be used with Buildroot. The only requirement is that the toolchain supports the sysroot feature, which is very common in most toolchains.

uClibc 0.9.30 is available

About one year and a half after the release of the previous stable version, the release of uClibc 0.9.30 is a great event in the embedded Linux community. uClibc is a replacement for the glibc C library, implementing most of the features of glibc, while retaining a much smaller size and an incredible level of configurability.

The only changelog available is a list of Subversion commits that occurred between the 0.9.29 and the 0.9.30 releases, so it is quite difficult to extract what are the important bits. However, a news from August 2008 on uClibc.org website gives an idea of what happened in the 0.9.30 version :

  • a lot of fixes for the various architectures, and other tweaks and improvements
  • an improved configurability that allows to enable/disable a larger number of features, now including
    • Realtime-related family of SUSv functions (option UCLIBC_HAS_REALTIME, which enables aio_*() functions, mq_*() functions, mlock() family of functions, sched_*() functions, sem_*() functions, a few signal-related functions and the timer_*() functions). Threading support requires the realtime functions, so it depends on this option.
    • Advanced realtime-related family of SUSv functions (option UCLIBC_HAS_ADVANCED_REALTIME, which enables a few advanced clock_*() and mq_*() functions, and a large number of posix_spawnattr_*() and posix_spawn_*() functions)
    • epoll (option UCLIBC_HAS_EPOLL)
    • extended attributes (option UCLIBC_HAS_XATTR)
    • other options to enable/disable compatibility/deprecated APIs
  • it is now possible to build uClibc without network support at all. The global option is UCLIBC_HAS_NETWORK_SUPPORT, and can be further refined with UCLIBC_HAS_SOCKET to enable just the socket support (for example if only Unix sockets are used), UCLIBC_HAS_IPV4 to get IPv4 functionality, which of course requires the socket support, and UCLIBC_HAS_IPV6 for IPv6.

A quick look at the differences between the available options allows to see another set of features:

  • Support for the AVR32 and Xtensa architecture has been added
  • A configuration option to enable non-functional stubs for features that are not implemented on a given architecture. This option for example enables a stub fork() function on non-MMU architectures so that applications can easily be recompiled, without checking all the fork() sites from the beginning
  • Options to enable/disable Linux-specific or BSD-specific functions

The allnoconfig setup with shared library is reported to have been reduced by 30%, though the allnoconfig setup doesn’t necessarily correspond to a classical usage of uClibc.

The tarball is available here.