Bootlin toolchains 2023.11 released

Bootlin toolchains 2023.11Our toolchains.bootlin.com project offers a wide range of freely available pre-compiled cross-compilation toolchains, updated on a regular basis.

We are happy to announce the availability of version 2023.11 of our toolchains. Even though they are released in December (so one would expect the version number to be 2023.12), they are all generated using Buildroot 2023.11, hence the release number used for the toolchains.

Compared to the previous 2023.08 toolchains, here are the relevant changes:

  • Bleeding edge toolchains are now using gdb 14.1 instead of 13.2, glibc 2.38 instead of 2.37 and uclibc 1.0.45 instead of 1.0.43. They continue to use gcc 13.2 and binutils 2.41, as well as musl 1.2.4
  • Stable toolchains are now using gdb 13.2 instead of 12.1, glibc 2.38 instead of 2.37 and uclibc 1.0.45 instead of 1.0.43. They continue to use gcc 12.3 and binutils 2.40, as well as musl 1.2.4
  • The glibc version used has the fix for CVE-2023-4911
  • The gdb build has been fixed to no longer rely on uninstalled libbfd.so and libopcodes.so libraries
  • The zlib library, which was incorrectly present in the toolchain sysroot, is gone, fixing various build failures encountered with 2023.08 toolchains
  • There are now toolchains for m68k 68xxx based on uclibc and musl in addition to glibc, which was already supported

We have already submitted a patch to update the support of those toolchains in Buildroot, where they can be used as external toolchains.

Hopefully these toolchains will continue to be useful to the embedded Linux community. For any question, feedback or issue, you can use the Github issue tracker of the project.

Bootlin toolchains 2023.08 released

Bootlin toolchains 2023.08We are happy to announce that we have just published a new update of our freely available toolchains at toolchains.bootlin.com, version 2023.08.

For the record, we provide pre-built cross-compilation toolchains that work on x86-64 Linux machines, and targeting 43 different CPU architecture variants, with support for all 3 major C libraries: glibc, musl and uClibc-ng. For each toolchain, we provide two versions: a stable one that uses GCC/binutils/GDB versions next to the last, and a bleeding-edge one that uses the very latest GCC/binutils/GDB versions.

In this 2023.08 release, we have:

  • Updated the bleeding-edge toolchains to gcc 13.2, binutils 2.41, gdb 13.2, kernel headers 5.10, glibc 2.37, musl 1.2.4 or uclibc-ng 1.0.43
  • Updated the stable toolchains to gcc 12.3, binutils 2.40, gdb 12.1, kernel headers 4.14, glibc 2.37, musl 1.2.4 or uclibc-ng 1.0.43
  • Marked the sparcv8 toolchain as obsolete as sparc support in GCC has been broken for several releases, and the last working version of GCC for sparc has been dropped from Buildroot

A special thanks to Romain Naour from Smile who helped investigate and resolve some of the issues encountered in the preparation of those 2023.08 toolchains.

If you encounter any issue in the usage of those toolchains, or miss the support for a specific feature or architecture variant, let us know through the issue tracker. We hope those toolchains will continue to be useful to the community.

Bootlin toolchains integration in Buildroot

Since 2017, Bootlin is freely providing ready-to-use pre-built cross-compilation toolchains at https://toolchains.bootlin.com/. We are now providing over 150 toolchains, for a wide range of CPU architectures, covering the glibc, uClibc-ng and musl C libraries, with up-to-date gcc, binutils, gdb and C library support.

We recently contributed an improvement to Buildroot that allows those toolchains to very easily be used in Buildroot configurations: the Bootlin toolchains are now all known by Buildroot as existing external toolchains, next to toolchains from other vendors such as ARM, Synopsys and others.

If you are building a Buildroot system for a CPU architecture variant that has a matching toolchain available from bootlin.toolchains.com, then Bootlin toolchains will naturally show up in the Toolchain sub-menu, when the selected Toolchain type is External toolchain. For example, if the selected CPU architecture is ARM little endian Cortex-A9, with VFP you will see:

Bootlin toolchain selection

Once Bootlin toolchains is selected, a new sub-option Bootlin toolchain variant appears, which allows to choose between the different toolchains applicable to the selected CPU architecture:

Bootlin toolchain choice

This hopefully should make Bootlin toolchains easier to use for Buildroot users.

Internally, this support for Bootlin toolchains in Buildroot is generated and updated using the support/scripts/gen-bootlin-toolchains script. In addition to making the toolchains available to the user, it allows generates some Buildroot test cases for each toolchain, so that each of those configuration is tested by Buildroot continuous integration, see support/testing/tests/toolchain/test_external_bootlin.py.

Bootlin toolchains 2020.08 released

Bootlin toolchainsWe are happy to announce a new release of the freely available cross-compilation toolchains we provide at toolchains.bootlin.com, version 2020.08-1.

Here are the main changes compared to our previous 2020.02 release:

  • Bleeding edge toolchains are now using: gcc 10.2, binutils 2.34, gdb 9.2, kernel headers 5.4, glibc 2.31, musl 1.2.0, uclibc-ng 1.0.34
  • Stable toolchains are using: gcc 9.3, binutils 2.33, gdb 8.3, kernel headers 4.9, glibc 2.31, musl 1.2.0, uclibc-ng 1.0.34
  • Fortran support has been enabled in all tolchains
  • Several new CPU architecture variants are supported, each with a new toolchain
  • Boot testing in Qemu was added for PowerPC64 E5500, NIOSII and m68k MCF5208.

In addition, it is worth mentioning that all those Bootlin toolchains are now directly accessible from Buildroot: make menuconfig shows the Bootlin toolchains available for the current selected CPU architecture, and Buildroot is able to automatically download and use the toolchain. This feature will be available starting from Buildroot 2020.11:

Thanks again to the entire Buildroot community, and especially Romain Naour, for all the fixes and improvements related to toolchain support that make this project possible. In the next weeks, we hope to be able to deliver further updated bleeding-edge toolchains, with glibc 2.32 and binutils 2.35. Stay tuned!

If you face any issue, or need additional features in those toolchains, do not hesitate to report an issue in our issue tracker.

Updated cross-compilation toolchains, RISC-V 64 bit toolchain added

RISC-V 64 toolchainWe have just published an updated version of the cross-compilation toolchains available at toolchains.bootlin.com.

The significant changes are:

  • A RISC-V 64 bit toolchain is now provided, following the addition of support for this architecture to the Buildroot project.
  • The stable toolchains are now using gcc 7.3.0 (instead of 6.4.0), gdb 7.12.1 (instead of 7.11.1), kernel headers 4.1.52 (instead of 4.1.49), glibc 2.27 (instead of 2.26), musl 1.1.19 (instead of 1.1.18) and uclibc 1.0.30 (instead of 1.0.28). We are still using a 7.x gdb version because the 8.x versions need C++11 support, which requires a recent enough host compiler, which in turn requires using a more modern distribution. Thus, those toolchains would be unusable with older distributions as they would require a recent glibc version on the host. Currently, our stable toolchains are still built within an old Debian Squeeze system, for maximum compatibility with old distributions.
  • The bleeding-edge toolchains are still using gcc 8.2.0, but gdb is now 8.1.1 (instead of 8.1), kernel headers 4.14.80 (instead of 4.14.57), glibc 2.28 (instead of 2.27), musl 1.1.20 (instead of 1.1.19).

We will continue to update those toolchains with more recent versions of gcc, binutils, gdb and the different C libraries, and add support for more architectures. Do not hesitate to ask for additional features or report any issue encountered when using those toolchains in our bug tracker.

Buildroot 2011.02 released, with many interesting updates and commercial support!

Buildroot logoAs usual, the latest Buildroot version has been released just in time on the last day of the month: Buildroot 2011.02 is available for download!

This release of the increasingly popular embedded Linux build system provides new interesting features and updates:

  • Support of external toolchains has been improved with support for toolchain profiles. Those are predefined configurations for well-known toolchains such as the CodeSourcery ones for ARM, PowerPC, MIPS and SuperH. Buildroot is now capable of automatically downloading and installing those external toolchains, which is much easier than downloading them manually. It’s now easy to provide users with Buildroot configurations that use well known toolchains, without requiring them to pre-install anything specific.
  • Support for board configurations has been completely rewritten and largely simplified. All board-specific Makefile and configuration options have been removed, and instead, each board is represented by a single, simple (less than 20 lines) defconfig file, in the configs/ directory. In addition to the existing configuration, we have added support for the Mini2440 platform but also for many Qemu emulated platforms: Qemu ARM Versatile, Qemu MIPSel Malta, Qemu PowerPC G3 Beige, Qemu SH4 r2d and Qemu x86. Those configurations allow to easily produce a known-to-work system for the Qemu emulator, making Buildroot even easier to start working on your embedded Linux system. See the documentation for more details on how to add your own board support.
  • Support for the Blackfin architecture has been added, thanks to Mike Frysinger. This support came along with a lot of fixes to make Buildroot work better for non-MMU architectures, since Blackfin is the first actively supported non-MMU architecture in Buildroot. There will certainly be further improvements to support non-MMU architectures, and hopefully additional non-MMU platforms will be added. For those platforms, Buildroot is generally a very good embedded Linux build system, as those architectures are typically used for small to medium sized systems, with a relatively limited number of components.
  • The Crosstool-NG back-end has been improved and extended to support more Buildroot options, and has been upgraded to a newer Crosstool-NG version. This back-end is the third mode for Buildroot toolchain: it allows Buildroot to use Crosstool-NG as the toolchain generator.
  • Ccache support has been reworked and it now works properly. Since Buildroot often requires complete rebuilds from scratch, having the ccache compiler cache is very nice. On my laptop, compiling from scratch a sample Buildroot system was taking 5 minutes and 29 seconds without ccache, and now only takes 3 minutes and 40 seconds with ccache enabled and the cache already filled by a previous build.
  • A new CMake infrastructure has been added for packages, next to the existing generic and autotools infrastructure. For the moment, only two packages are using the infrastructure (cdrkit and libcuefile), but CMake is an increasingly popular build system and we will definitely see more packages using it in the future. Moreover, Buildroot generates a CMake toolchain file that describes the toolchain used by Buildroot, and which makes it very easy to cross-compile external libraries/applications for the Buildroot system using cmake -DCMAKE_TOOLCHAIN_FILE=/path/to/buildroot/output/toolchainfile.cmake.
  • A very nice cleanup job of the internal toolchain build process has been started by Gustavo Zacarias. The build process of binutils, gmp, mpfr and mpc has been migrated to proper packages, and this will also be done for gcc and gdb in the future.
  • As preliminary steps towards the generation of a standalone SDK from Buildroot, two important changes have been made. First, the staging directory is now inside $(O)/host/usr/PLATFORM-TUPLE/sysroot/, but a symbolic link from $(O)/staging has been kept for compatibility. This change will allow the $(O)/host directory to be the standalone SDK in the future. The second change is on pkg-config: its configuration has been adjusted so that it behaves properly to compile target packages without needing any environment variables or options. It makes the Buildroot pkg-config much easier to use to compile external applications.
  • The Python package has been upgraded to the latest Python version, 2.7.1. This was needed since a long time, since the version of Python we had in Buildroot was only 2.4. Moreover, the package has been completely rewritten, with more options, and has been tested on several platforms. Two external Python modules, python-mad and python-serial have also been added as packages, to show how such modules can be integrated into Buildroot.
  • A set of packages to add support in GStreamer for the TI DSP codecs has been added: gst-dsp, gst-omapfb, tidsp-binaries, dsp-tools, thanks to Felipe Contreras.
  • We have a bunch of new packages as well: mpd, the Music Player Daemon with many audio codecs and libraries, the dhrystone and whetstone benchmarks and other tools such as xmlstarlet, fbgrab, irda-utils, lsuio, etc.
  • Many other packages have been upgraded or fixed, and the results of our random configuration builds are much, much better than they were in the past.

As a Bootlin engineer, I have again contributed significantly to this release: Peter Korsgaard, the Buildroot maintainer, has done 171 commits, Gustavo Zacarias has done 119 commits and I have done 103 commits. The next committer is Mike Frysinger (for the great Blackfin support) with 22 commits.

It is with this great Buildroot knowledge and experience that Bootlin has launched a few weeks ago an official offering of Buildroot commercial support. If you are using Buildroot for your embedded product, or want the buyers of your hardware platform to have a simple but efficient embedded Linux build system and you need help, development or consulting, do not hesitate to contact us.

Crosstool-NG 1.7.0, Bootlin contributed basic Blackfin support

Yann E. Morin, maintainer of Crosstool-NG, has just announced version 1.7.0 of his toolchain building tool we like so much at Bootlin. For the record, Crosstool-NG allows to build cross-compiling toolchains for a wide-range of architectures, using either glibc, uClibc, eglibc or newlib, and everything is configured through a menuconfig interface, familiar to all embedded Linux developers.

Blackfin architectureBootlin has contributed to this release, by adding some support for the Blackfin architecture, on which we have been working recently. Crosstool-NG is now capable of generating a FDPIC cross-compiling toolchain for Blackfin. FDPIC allows to use shared libraries even on no-MMU architectures like the Blackfin. This support of Blackfin in Crosstool-NG is only the beginning, a lot of work remains to be done to make sure that the toolchain works really well, and to support FLAT binaries and bare-metal as well.

Here are the patches that Bootlin has contributed for this release :

The other major changes for this release are :

  • two new architectures have been added: Blackfin and mips64
  • building canadian-crosses has been enhanced
  • experimental support for gcc-4.5 has been added
  • eglibc can be optimized for size (instead of speed)
  • companion libraries can be built statically, removing the need for a wrapper
  • many components versions have been added, and associated patchsets updated
  • some less important new features, or enhancements for stability and usability
  • a lot of bug-fixes, of which some to help on Darwin & *BSD

The 1.7.0 release can be downloaded at http://ymorin.is-a-geek.org/download/crosstool-ng/crosstool-ng-1.7.0.tar.bz2 and the homepage of the Crosstool-NG project is http://ymorin.is-a-geek.org/projects/crosstool. Enjoy !

Crosstool-NG 1.5.0 released, with new features!

Crosstool-NG, the successor of Crosstool, is a tool that automates the complicated process of building a cross-compilation toolchain. It provides a nice menuconfig interface to fine tune the configuration of the toolchain, before creating the toolchain automatically by retrieving, extracting, patching, configuring, compiling and installing the different components in the right order, with the right arguments and configuration.

Yann E. Morin, the maintainer of Crosstool-NG has just announced the release of Crosstool-NG 1.5.0, with the following new features:

  • Support for gcc 4.4
  • Experimental support for canadian-cross toolchains. Canadian-cross toolchains are toolchains that are built on machine A, to run on machine B and generate code for machine C, while usual cross-compilation toolchain are built on machine A, to run on machine A and generate code for machine B
  • Experimental support for AVR32, with support for operation as MMU-less, thanks to the newlib C library

In addition to these important features, bugs have been fixed and improvements have been made. Yann also switched the development of Crosstool-NG from Subversion to Mercurial, in order to ease community participation in the improvement of Crosstool-NG.

By the way, if you are interested in Crosstool-NG, don’t miss Yann E. Morin’s talk at the Embedded Linux Conference Europe 2009. See the program for details.

Buildroot simplified for users!

Buildroot logoYesterday, a set of patches I’ve authored that aims at simplifying Buildroot for users has been merged into the official version of the project, and will therefore be part of the next stable release (scheduled for November, according to our 3 months release cycle). This work is probably my major contribution to Buildroot, outside of external toolchain support and various fixes here and there. Here are quick details about the improvements brought by these patches :

  • Remove the “project” feature. The project feature removal was the main point of this patch set. This feature, that allows to compile a system for different, but very similar platforms, without recompiling everything from scratch, was rarely used and introduced a lot of complexity in the usage of Buildroot for newcomers. Who hasn’t been confused by this project_build_arm directory? This thing is gone now.
  • Remove the BOARD/LOCAL feature, which duplicates another way of adding support for new targets in Buildroot. This is the kind of feature that has been added at the time Buildroot was basically unmaintained, when nobody was able to say « Hey, but you’re just trying to-reimplement something that already exists »
  • Move all output directories in an output directory. By default, when Buildroot is compiled, it generates several directories in the middle of its source code. Now, with this patch, everything is grouped into an output directory, unless out-of-tree compilation is used, of course (with O=)
  • Remove TOPDIR_PREFIX and TOPDIR_SUFFIX since the same effect could already be done using out-of-tree compilation with O=. Another duplicated feature that should never have reached the tree.
  • Rename the output directories. Now that everything is properly stored in an output directory, it was time to rename the subdirectories to make them more meaningful. So now, we have build where all packages are built, images that contains the final binary images of the root filesystem and the kernel, staging which contains the staging directory (all packages installed with their development headers and libraries), target that contains the root filesystem for the target (without the device files), host that contains the installation of the host tools that Buildroot requires for its execution, stamps that contains the stamp files used by Buildroot to keep track of the compilation progress. Therefore, all directories such as build_ARCH or toolchain_build_ARCH have disappeared.
  • Major documentation update, to of course make sure that our documentation is up-to-date with the latest changes.

Getting all these changes mainlined is really a nice thing. I also have tons of other ideas to improve Buildroot infrastructure, and I’m sure the coming Buildroot Developer Day will be a great opportunity to discuss these.

Switching between toolchains made easy!

It is quite common to have several toolchains and to switch back and forth between them while doing development. At least, this is something I do a lot when doing Buildroot development and debugging. As I hate typing full paths all the time, I usually put the toolchain bin/ directory into my $PATH variable, so that I can easily access the toolchain binaries. However, it means that everytime you run a new shell or everytime you want to switch from one toolchain to another, you need to modify the PATH variable manually by re-exporting it. Of course, one could easily put all the bin/ directories of all toolchains in the PATH, but that would clutter what is shown when I do arm-TAB-TAB, and that’s not nice.

So, I ended up hacking a few lines of Bash that provide me with two new commands: xtoolsadd, to add a toolchain to my PATH and xtoolsdel, to remove a toolchain from my PATH. These commands work by making the assumption that all toolchains are stored in a common directory. In my case /usr/local/xtools/ contains all the toolchains, one per subdirectory. So I have /usr/local/xtools/arm-unknown-linux-gnu for an ARM glibc-based non-EABI toolchain, or /usr/local/xtools/arm-unknown-linux-uclibcgnueabi for an ARM uClibc-based EABI toolchain).

So, now I can do things such as

xtoolsadd arm-unknown-linux-gnu

or

xtoolsdel arm-unknown-linux-uclibcgnueabi

Because these commands must modify the PATH variable of the current shell, they cannot be implemented as separate shell scripts, so they are in fact implemented as functions in my ~/.bashrc script. And in addition to these functions, I also implemented completion, so when you do xtoolsadd TAB-TAB, it gives you a choice of toolchains, and if you start typing one and press TAB, it will just automatically complete for you. The same thing works with xtoolsdel, of course.

To make this work, here is what you need to put in your ~/.bashrc file:

export XTOOLSDIR=/usr/local/xtools

xtoolsadd() {
    TOOLCHAINDIR=$XTOOLSDIR/$1/bin
    if [ ! -d $TOOLCHAINDIR ] ; then
        echo "Directory $XTOOLSDIR doesn't exist"
    else
        case "$PATH" in
            *"$XTOOLSDIR"*)
                ;;
            *)
                export PATH=$TOOLCHAINDIR:$PATH
        esac
    fi
}

xtoolsdel() {
    TOOLCHAINDIR=$XTOOLSDIR/$1/bin
    NEWPATH=
    found=0
    for i in $(echo $PATH | tr ":" "\n") ; do
        if [ $i == $TOOLCHAINDIR ] ; then
            found=1
        else
            NEWPATH=$NEWPATH:$i
        fi
    done
    if [ $found == 0 ] ; then
        echo "$1 is not in your PATH"
    else
        export PATH=$NEWPATH
    fi
}

_xtoolsadd() {
    cur=${COMP_WORDS[COMP_CWORD]}
    LIST=$(ls -1 $XTOOLSDIR | tr "\n" " ")
    COMPREPLY=( $( compgen -W "$LIST" -- $cur))
}

_xtoolsdel() {
    cur=${COMP_WORDS[COMP_CWORD]}
    LIST=$(echo $PATH | tr ":" "\n" | grep "^$XTOOLSDIR" | sed "s%$XTOOLSDIR/\([^/]*\)/bin%\1%")
    COMPREPLY=( $( compgen -W "$LIST" -- $cur))
}

complete -F _xtoolsadd xtoolsadd
complete -F _xtoolsdel xtoolsdel

The shell code may not be perfect or fully optimized, but it works. Of course, if you have suggestions or questions, don’t hesitate to post comments!