bootlin / toolchains-builder Goto Github PK

Home Page: http://toolchains.free-electrons.com

Shell 90.51% Dockerfile 9.49%

toolchains-builder's Introduction

Toolchains builder

The goal of this project is to automate the build of a wide range of toolchains using Buildroot.

Since making a per-toolchain configuration is not viable, some scripts have been made to allow a more flexible configuration. You can find all the config fragments in the configs folder.

update_gitlab-ci.sh

This script simply makes the different valid fragments from all the possible combinations of architecture, libc, and version, found in the configs folder.

It autocommits the generated fragments in a builds branch. The fragments are in the frags folder, and a .gitlab-ci.yaml file is created to trigger the builds if pushed to a well configured Gitlab hosted project.

build.sh

This is the main script handling the build, the test, and the packaging of the toolchain. If you typically want to recreate the whole build process, just run that as root (for chroot). It is wise to do that in some sort of container, and not on your bare system.

build_chroot.sh

This is the script called in the chroot environment, that simply builds the toolchain without testing it or packaging anything. If you simply want to reproduce the build for debugging, it's probably this script your looking for.

All these scripts can be called without arguments to get their usage information.

toolchains-builder's People

Contributors

Stargazers

Watchers

toolchains-builder's Issues

i686 GCC 7.2 + glibc breaks C++ std::signbit

The bleedging-edge toolchain with GCC 7.2 and glibc for i686 has broken support for std::signbit:

#include <iostream>
#include <cmath>

int main()
{
    std::cout << std::boolalpha
              << "signbit(+0.0) = " << std::signbit(+0.0) << '\n'
              << "signbit(-0.0) = " << std::signbit(-0.0) << '\n';
}

 $ /home/jkt/work/prog/_build/br-geode/host/bin/i686-linux-g++ --sysroot=/home/jkt/work/prog/_build/br-geode/host/i686-buildroot-linux-gnu/sysroot -std=c++14 -o /dev/null -c foo.cpp 
In file included from /home/jkt/work/prog/_build/br-geode/host/opt/ext-toolchain/i686-buildroot-linux-gnu/include/c++/7.2.0/cmath:45:0,
                 from foo.cpp:2:
foo.cpp: In function ‘int main()’:
foo.cpp:7:45: error: ‘__builtin_signbit’ is not a member of ‘std’
               << "signbit(+0.0) = " << std::signbit(+0.0) << '\n'
                                             ^
foo.cpp:7:45: note: suggested alternative:
<built-in>: note:   ‘__builtin_signbit’
foo.cpp:8:45: error: ‘__builtin_signbit’ is not a member of ‘std’
               << "signbit(-0.0) = " << std::signbit(-0.0) << '\n';
                                             ^
foo.cpp:8:45: note: suggested alternative:
<built-in>: note:   ‘__builtin_signbit’

I know that the code works fine with native GCC 6.3.0 (Gentoo) as well as Linaro ARM 6.3.1 and also with GCC 6.3.x as produced by Buildroot itself. An online test at godbolt.org shows that GCC 7.2 appears to work, so I'm reporting this issue here.

Support -no-canonical-prefixes argument to gcc

Hi,

It appears that the gcc executables in the toolchains hosted at https://toolchains.bootlin.com/ do not support the -no-canonical-prefixes argument.

For example, if I run the following commands using the x86-64-core-i7 toolchain:

tar -xf x86-64-core-i7--glibc--stable-2020.08-1.tar.bz2
cd  x86-64-core-i7--glibc--stable-2020.08-1/bin
./x86_64-linux-gcc -E -xc++ - -v

I get the following output:

Using built-in specs.
COLLECT_GCC=/home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/x86_64-linux-gcc.br_real
Target: x86_64-buildroot-linux-gnu
Configured with: ./configure --prefix=/opt/x86-64-core-i7--glibc--stable-2020.08-1 --sysconfdir=/opt/x86-64-core-i7--glibc--stable-2020.08-1/etc --enable-static --target=x86_64-buildroot-linux-gnu --with-sysroot=/opt/x86-64-core-i7--glibc--stable-2020.08-1/x86_64-buildroot-linux-gnu/sysroot --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --with-gmp=/opt/x86-64-core-i7--glibc--stable-2020.08-1 --with-mpc=/opt/x86-64-core-i7--glibc--stable-2020.08-1 --with-mpfr=/opt/x86-64-core-i7--glibc--stable-2020.08-1 --with-pkgversion='Buildroot 2020.08-14-ge5a2a90' --with-bugurl=http://bugs.buildroot.net/ --without-zstd --enable-libquadmath --enable-tls --enable-threads --without-isl --without-cloog --with-arch=corei7 --enable-languages=c,c++,fortran --with-build-time-tools=/opt/x86-64-core-i7--glibc--stable-2020.08-1/x86_64-buildroot-linux-gnu/bin --enable-shared --disable-libgomp
Thread model: posix
gcc version 9.3.0 (Buildroot 2020.08-14-ge5a2a90) 
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=corei7'
 /home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../libexec/gcc/x86_64-buildroot-linux-gnu/9.3.0/cc1plus -E -quiet -v -iprefix /home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/ -isysroot /home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/x86_64-buildroot-linux-gnu/sysroot -D_GNU_SOURCE - -mtune=generic -march=corei7
ignoring duplicate directory "/home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/../../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/../../../../x86_64-buildroot-linux-gnu/include/c++/9.3.0"
ignoring duplicate directory "/home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/../../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/../../../../x86_64-buildroot-linux-gnu/include/c++/9.3.0/x86_64-buildroot-linux-gnu"
ignoring duplicate directory "/home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/../../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/../../../../x86_64-buildroot-linux-gnu/include/c++/9.3.0/backward"
ignoring duplicate directory "/home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/../../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/include"
ignoring nonexistent directory "/home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/x86_64-buildroot-linux-gnu/sysroot/usr/local/include"
ignoring duplicate directory "/home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/../../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/include-fixed"
ignoring duplicate directory "/home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/../../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/../../../../x86_64-buildroot-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/../../../../x86_64-buildroot-linux-gnu/include/c++/9.3.0
 /home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/../../../../x86_64-buildroot-linux-gnu/include/c++/9.3.0/x86_64-buildroot-linux-gnu
 /home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/../../../../x86_64-buildroot-linux-gnu/include/c++/9.3.0/backward
 /home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/include
 /home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/include-fixed
 /home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/bin/../lib/gcc/x86_64-buildroot-linux-gnu/9.3.0/../../../../x86_64-buildroot-linux-gnu/include
 /home/jheaff1/Downloads/x86-64-core-i7--glibc--stable-2020.08-1/x86_64-buildroot-linux-gnu/sysroot/usr/include
End of search list.

Notice the paths at the bottom of the console output above has absolute paths. Now, if i run the same gcc command but add the -no-canonical-prefixes argument, I get the same output. I would expect that the paths at the bottom of the console output be relative paths. If I run the same commands but for the official arm gcc toolchain, I get the following output:

Using built-in specs.
COLLECT_GCC=./arm-none-eabi-gcc
Target: arm-none-eabi
Configured with: /mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/src/gcc/configure --target=arm-none-eabi --prefix=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-native --libexecdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-native/lib --infodir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/install-native/arm-none-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-gmp=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-native/host-libs/usr --with-mpfr=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-native/host-libs/usr --with-mpc=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-native/host-libs/usr --with-isl=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-native/host-libs/usr --with-libelf=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/build-native/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Arm Embedded Toolchain 10-2020-q4-major' --with-multilib-list=rmprofile,aprofile
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20201103 (release) (GNU Arm Embedded Toolchain 10-2020-q4-major) 
COLLECT_GCC_OPTIONS='-E' '-v' '-fno-canonical-system-headers' '-mcpu=arm7tdmi' '-mfloat-abi=soft' '-marm' '-march=armv4t'
 ./../lib/gcc/arm-none-eabi/10.2.1/cc1plus -E -quiet -v -iprefix ./../lib/gcc/arm-none-eabi/10.2.1/ -isysroot ./../arm-none-eabi -D__USES_INITFINI__ - -mcpu=arm7tdmi -mfloat-abi=soft -marm -march=armv4t -fno-canonical-system-headers
ignoring duplicate directory "./../lib/gcc/../../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/include/c++/10.2.1"
ignoring duplicate directory "./../lib/gcc/../../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/include/c++/10.2.1/arm-none-eabi"
ignoring duplicate directory "./../lib/gcc/../../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/include/c++/10.2.1/backward"
ignoring duplicate directory "./../lib/gcc/../../lib/gcc/arm-none-eabi/10.2.1/include"
ignoring nonexistent directory "./../arm-none-eabi/usr/local/include"
ignoring duplicate directory "./../lib/gcc/../../lib/gcc/arm-none-eabi/10.2.1/include-fixed"
ignoring duplicate directory "./../lib/gcc/../../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/include"
ignoring nonexistent directory "./../arm-none-eabi/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 ./../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/include/c++/10.2.1
 ./../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/include/c++/10.2.1/arm-none-eabi
 ./../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/include/c++/10.2.1/backward
 ./../lib/gcc/arm-none-eabi/10.2.1/include
 ./../lib/gcc/arm-none-eabi/10.2.1/include-fixed
 ./../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/include
End of search list.

Notice how the paths at the bottom of the console log are relative paths.

The motivation for resolving this issue is that I would like to use your x86-64-corei7 toolchain to provide a hermetic gcc toolchain within the Bazel build system. Sadly your toolchains would not play nicely with Bazel due to this issue

backspace broken in all gdbs

Steps to reproduce:

Run aarch64-linux-gdb
Type "foo" followed by a backspace (or ctrl-H, or ctrl-U)

Results:

Instead of rewinding the cursor and removing the previous character, each backspace appends a space to the cmdline.

More information:

$ ldd <...>/aarch64--glibc--stable-2018.02-2/bin/aarch64-linux-gdb 
        linux-vdso.so.1 =>  (0x00007fffd6bff000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003fe7e00000)
        libncurses.so.6 => <...>/aarch64--glibc--stable-2018.02-2/bin/../lib/libncurses.so.6 (0x00007fe757063000)
        libm.so.6 => /lib64/libm.so.6 (0x0000003fe8a00000)
        libexpat.so.1 => <...>/aarch64--glibc--stable-2018.02-2/bin/../lib/libexpat.so.1 (0x00007fe756e3b000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003fe8200000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003fe7a00000)

On Fedora 27, LD_PRELOAD=/usr/lib64/libncurses.so.6.0 host/bin/x86_64-linux-gdb works around the problem, indicating it's something inside the bundled libncurses.so.6. (RHEL 6 only provides ncurses 5.7, so this trick is unavailable there.)

Affected releases:

2017.05 aarch64 glibc stable
2018.02 aarch64 glibc stable
unknown microblaze toolchain
unknown x86 toolchain

Affected host distributions:

RHEL 6.5
Fedora 27

(Haven't tested others.)

Is it possible to add host tools to the SDK/ cross-tool chain ?

Hi ,

I would like to add cmake, maven and python native support for the host machine along with the SDK ( build = host! = target). So the host system running the tool chain doesn't need to install cmake and python and all its dependencies so that the SDK is self-contained with all native packages and its dependencies ? These packages are need on the host machine but not on the target machine .

or Is there any current mechanism that allows to do it ? The main reason for doing this is, i would like to distribute the SDK as a debian pacakge with self contained host utilities.

OpenMP

Please provide OpenMP in the toolchains.
It would be great to provide it at least for linux-arm64, linux-armv5, linux-armv7, linux-mips, linux-s390x

For example, dockcross/dockcross@78b49e9 provides these.

musl-libc missing for armv7m

Unclear why (it may simply be a documentation issue), but only uclibc is supported in the drop-down for armv7m architectures currently. I'm specifically interested in musl-libc on such a platform, so if it is possible, I'd love to see it, and if not, I'd also be interested in what the blocking problem is.

Nice work

Hey, thx for your awesome work!
This tool was made possible because of you https://github.com/nongiach/arm_now

loongarch64: New architecture support needed

loongarch64 is a new RISC architecture which has recently been supported by the open source community.
On :

binutils 2.40
gcc 12.1
gdb 13.1
glibc 2.36
qemu 7.2.0

An overview of the development status of loongarch64 in the open source community can be seen here: https://areweloongyet.com/

enable Python support in GDB

The aarch64--glibc--stable gdb says:

(gdb) python
>end
Scripting in the "Python" language is not supported in this copy of GDB.

There are some pretty important tools distributed as GDB Python scripts, such as Linux's gdb scripts (including dmesg dumper), and this one-off debug a relocated executable script.

Please enable Python support in GDB. Thanks!

Enable ppc64le qemu

I'd like to enable boot tests for the ppc64le toolchains. buildroot master has support for a qemu_ppc64le_pseries machine as of 9d5b5b7.

Here's a change that enables the configuration:

https://github.com/shenki/toolchains-builder/tree/enable-ppc64le

However I think we need to wait until the toolchains-builder uses a newer release of buildroot?

I'm happy to write and test patches with some guidance as to what needs to be done. Thanks!

RHEL6 host support (rpath problem)

Most of the toolchain (gcc, objdump, etc) works great on RHEL6. One exception though is gdb, which can't find libncurses.so.6. (RHEL 6.* and CentOS 6.* seem to provide only libncurses.so.5.)

However, I see that aarch64--glibc--stable/lib/libncurses.so.6 is actually included, so why isn't it found?

$ chrpath -l aarch64-buildroot-linux-gnu-gdb
aarch64-buildroot-linux-gnu-gdb: RPATH=/tmp/aarch64--glibc--stable/usr/lib

Needless to say, I didn't install my aarch64--glibc--stable toolchain into /tmp. Editing rpath fixes it.

$ chrpath -r '$ORIGIN/../lib' aarch64-buildroot-linux-gnu-gdb
aarch64-buildroot-linux-gnu-gdb: RPATH=/tmp/aarch64--glibc--stable/usr/lib
aarch64-buildroot-linux-gnu-gdb: new RPATH: $ORIGIN/../lib
$ aarch64-buildroot-linux-gnu-gdb
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=aarch64-buildroot-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
/home/hblancha/.gdbinit:99: Error in sourced command file:
Scripting in the "Python" language is not supported in this copy of GDB.
(gdb)

I guess another alternative is to set LD_LIBRARY_PATH (chrpath is not installed by default, any many of these users lack root permissions), but far better to correct the rpath in the binary.

Build local toolchains

Hi,

I'm attempting to build a new toolchain locally but am running into some issues. I modified the armv7m.config file and ran the command: sudo ./build.sh armv7m--uclibc--cortexm3 test stable 2020-1-25.

I ended up getting these errors:

cp: cannot stat '/home/vagrant/toolchains-builder/frags/armv7m--uclibc--cortexm3.config': No such file or directory
Uploading build log
The authenticity of host 'toolchains.bootlin.com (51.254.149.199)' can't be established.
RSA key fingerprint is SHA256:eQBz/dpQC+2zY8kNtJZZraH6lZgTR1LMju1Colf5IgI.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'toolchains.bootlin.com,51.254.149.199' (RSA) to the list of known hosts.
[email protected]: Permission denied (publickey).
[email protected]: Permission denied (publickey).
lost connection
Toolchain build failed, not going further

I'm not entirely sure what I've done wrong here.

How to use the toolchains?

I downloaded the x86-core2 toolchain, but I don't know how to use it. In other toolchains I have been used there is a script that exports all the variables needed.

The aarch64 toolchain (gcc 10.2) isn't working

Running configuration tests
...
Checking for machine tuple...

/home/sergey/Projects/armlinux/toolchains/bootlin/10/aarch64-buildroot-linux-gnu/bin/aarch64-buildroot-linux-gnu-g++ -dumpmachine

aarch64-buildroot-linux-gnu
test config.qtbase.tests.machineTuple succeeded
Checking for valid makespec...

cd /home/sergey/Projects/orpaltech/qt-build/qt5/build/linux-sun50i-a64-drm-g++/qtbase/config.tests/verifyspec && /home/sergey/Projects/orpaltech/qt-build/qt5/build/linux-sun50i-a64-drm-g++/qtbase/bin/qmake "CONFIG -= qt debug_and_release app_bundle lib_bundle" "CONFIG += shared warn_off console single_arch" "QMAKE_CFLAGS += --sysroot=/home/sergey/Projects/orpaltech/boards/nanopi-a64/sysroot" "QMAKE_CXXFLAGS += --sysroot=/home/sergey/Projects/orpaltech/boards/nanopi-a64/sysroot" "QMAKE_LFLAGS += --sysroot=/home/sergey/Projects/orpaltech/boards/nanopi-a64/sysroot" -early "CONFIG += cross_compile" /home/sergey/Projects/orpaltech/qt-build/qt5/qtbase/config.tests/verifyspec

Info: creating stash file /home/sergey/Projects/orpaltech/qt-build/qt5/build/linux-sun50i-a64-drm-g++/qtbase/config.tests/.qmake.stash

cd /home/sergey/Projects/orpaltech/qt-build/qt5/build/linux-sun50i-a64-drm-g++/qtbase/config.tests/verifyspec && MAKEFLAGS= /usr/bin/make

/home/sergey/Projects/armlinux/toolchains/bootlin/10/aarch64-buildroot-linux-gnu/bin/aarch64-buildroot-linux-gnu-g++ -c -pipe -march=armv8-a -mtune=cortex-a53 --sysroot=/home/sergey/Projects/orpaltech/boards/nanopi-a64/sysroot -O2 -w -fPIC -I/home/sergey/Projects/orpaltech/qt-build/qt5/qtbase/config.tests/verifyspec -I. -I/home/sergey/Projects/orpaltech/qt-build/qt5/qtbase/mkspecs/devices/linux-sun50i-a64-drm-g++ -o verifyspec.o /home/sergey/Projects/orpaltech/qt-build/qt5/qtbase/config.tests/verifyspec/verifyspec.cpp
/home/sergey/Projects/armlinux/toolchains/bootlin/10/aarch64-buildroot-linux-gnu/bin/aarch64-buildroot-linux-gnu-g++ --sysroot=/home/sergey/Projects/orpaltech/boards/nanopi-a64/sysroot -Wl,-O1 -Wl,-rpath-link,/home/sergey/Projects/orpaltech/boards/nanopi-a64/sysroot/usr/lib/aarch64-buildroot-linux-gnu -Wl,-rpath-link,/home/sergey/Projects/orpaltech/boards/nanopi-a64/sysroot/lib/aarch64-buildroot-linux-gnu -o verifyspec verifyspec.o -lrt -lpthread -ldl -lz
/home/sergey/Projects/armlinux/toolchains/bootlin/10/aarch64-buildroot-linux-gnu/bin/../lib/gcc/aarch64-buildroot-linux-gnu/10.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: cannot find crt1.o: No such file or directory
/home/sergey/Projects/armlinux/toolchains/bootlin/10/aarch64-buildroot-linux-gnu/bin/../lib/gcc/aarch64-buildroot-linux-gnu/10.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: cannot find crti.o: No such file or directory
/home/sergey/Projects/armlinux/toolchains/bootlin/10/aarch64-buildroot-linux-gnu/bin/../lib/gcc/aarch64-buildroot-linux-gnu/10.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: cannot find -lrt
/home/sergey/Projects/armlinux/toolchains/bootlin/10/aarch64-buildroot-linux-gnu/bin/../lib/gcc/aarch64-buildroot-linux-gnu/10.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: cannot find -lpthread
/home/sergey/Projects/armlinux/toolchains/bootlin/10/aarch64-buildroot-linux-gnu/bin/../lib/gcc/aarch64-buildroot-linux-gnu/10.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: cannot find -ldl
/home/sergey/Projects/armlinux/toolchains/bootlin/10/aarch64-buildroot-linux-gnu/bin/../lib/gcc/aarch64-buildroot-linux-gnu/10.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: cannot find -lz
/home/sergey/Projects/armlinux/toolchains/bootlin/10/aarch64-buildroot-linux-gnu/bin/../lib/gcc/aarch64-buildroot-linux-gnu/10.2.0/../../../../aarch64-buildroot-linux-gnu/bin/ld: cannot find -lm
collect2: error: ld returned 1 exit status
make: *** [Makefile:68: verifyspec] Error 1
Note: Also available for Linux: linux-clang linux-icc

x86 host architecture

is there any plan to create toolchains for x86 host architecture?

Please support older kernels

Testing x86-i686--glibc--stable-2021.11-1.tar.bz2

gcc 10.3.0
kernel header 4.9.0

I get this error on debian stretch

# ./lzip-1.13-linux-i686gnu
FATAL: kernel too old
Aborted

currently using kernel 4.1...

# uname -a
Linux xxpc14850 4.1.48 #1 SMP Thu Dec 21 17:45:19 EST 2017 i686 GNU/Linux
#

# file lzip-1.13-linux-i686gnu
lzip-1.13-linux-i686gnu: ELF 32-bit LSB executable, Intel 80386
   version 1 (GNU/Linux), statically linked, for GNU/Linux 4.9.0, stripped

Perhaps adding something like

--enable-kernel=3.2.0 or
--enable-kernel=3.8.0 or
--enable-kernel=3.14.0
will fix this issue. I've been using other cross compilers, and have no issues using the latest gcc (11.3) to compile static apps that run on old distros

https://unix.stackexchange.com/questions/9705/can-new-glibc-versions-be-used-with-an-old-kernel

[x86-core2] "CPU ISA level is lower than required" issue with glibc 2.33

Hello,

When testing glibc 2.33 with x86-core2 toolchain, the system doesn't boot due to a kernel panic:

Run /sbin/init as init process
/lib/libc.so.6: CPU ISA level is lower than required
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

This is due to a new isa level check added by this commit:
"x86: Support GNU_PROPERTY_X86_ISA_1_V[234] marker [BZ #26717]"

We get this issue even by using the -cpu core2duo on the Qemu command line (core2duo should match the defconfig option BR2_x86_core2)...
The boot succeed as soon as we use a newer microarchitecture like Broadwell, Nehalem, SandyBridge, Skylake on the Qemu command line.

Any ideas?

Still supported? Updates?

Hi Thomas :) Just wondering if these toolchains are still supported. Are you planning on any updates? I see the latest was built using BR 2018.11 base. As you know there has been loads of updates since: to GCC, standard C libs, etc. It's helped out a lot using these as an external toolchain for some of our builds (for debugging plus the overall quicker builds). Thanks.

gold linker from binutils

I'm not sure if this is the right place to ask but would it be possible to start including the gold linker in artifacts?

aclocal is broken for sparc64--glibc--stable-2021.11-1

When using the provided aclocal, I'm getting the following error message:

Can't locate Automake/Config.pm in @inc (you may need to install the Automake::C
onfig module) (@inc contains: /builds/bootlin/toolchains-builder/build/sparc64--
glibc--stable-2021.11-1/share/automake-1.16 /etc/perl /usr/local/lib/x86_64-linu
x-gnu/perl/5.32.1 /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5
.32 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-g
nu/perl/5.32 /usr/share/perl/5.32 /usr/local/lib/site_perl) at /usr/src/cross/sp
arc64--glibc--stable-2021.11-1/bin/aclocal-1.16 line 35.
BEGIN failed--compilation aborted at /usr/src/cross/sparc64--glibc--stable-2021.
11-1/bin/aclocal-1.16 line 35.

I can fix this by setting the envvar PERL5LIB='/usr/src/cross/sparc64--glibc--stable-2021.11-1/share/automake-1.16', but then I run into this error:

aclocal-1.16: error: couldn't open directory '/builds/bootlin/toolchains-builder/build/sparc64--glibc--stable-2021.11-1/share/aclocal-1.16': No such file or directory

I imagine if I moved the install to the path that it was originally built with it would work, but it would be nice if that weren't required. And I suspect that this issue exists for many if not all other builds, but I haven't checked.

riscv64/glibc lacks gdb

version: 2020.08

In the bin folder, there is no riscv64-buildroot-linux-gnu-gdb.

RSS feed for the news section

Would it be possible to read the news section as RSS feed?

Newest toolchains build broken OpenBIOS firmwares

I've tried the two newest stable builds and the newest bleeding edge build and they all produce firmwares that cause QEMU to above. In contrast, the firmwares built with kernel.org toolchains work fine. For more details, see this OpenBIOS issue: openbios/openbios#15.

invalid options persist in fragments

Currently, OpenMP support is flagged in configs/optionals/*.config

This fragment gets applied to all configurations and is persisted into the release fragment, however, this option is not supported for microblaze and arc targets https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/gcc/Config.in.host#L136

There probably needs to be an additional step to make sure that optionals persist after a make savedefconfig, or if they're really optionals, we need to run make savedefconfig and copy out the result so that we do not incorrectly flag support that buildroot's gen-bootlin-toolchains may accidentally apply.

diff --git a/update_gitlab-ci.sh b/update_gitlab-ci.sh
index 26214b3..288315d 100755
--- a/update_gitlab-ci.sh
+++ b/update_gitlab-ci.sh
@@ -127,6 +127,9 @@ function gen_fragment {
             if [[ $name = $optional_m ]]; then
                optionals="${optionals} ${optional}"
                 cat "${base_dir}/configs/optionals/$optional" >> ${config_file}
+                cp ${config_file} ${br_path}/.config
+                make -C ${br_path} savedefconfig 2>&1 1>/dev/null
+                cp ${br_path}/defconfig ${config_file}
             fi
         done
         mv ${config_file} ${frag_dir}/${release_name}.config

ncurses terminfo path

The host ncurses in Buildroot forces /usr/share/terminfo as the location for terminfo data. However, Ubuntu installs the terminfo data in /lib/terminfo. Due to this, when running gdb, backspace doesn't work, unless one does export TERMINFO=/lib/terminfo/.

Add more powerpc flavors

We are actively using 405, e300 and e500v2. Would be great if you could add support for those.

Builds for arm64 hosts

With the availability of ARM-based Macs, Chromebooks, Raspberry Pis, etc., it would be useful to have the toolchains released for arm64 hosts.

GCC D cross-compiler

Supported in a few architectures, I think it does support more architectures. it may also work with musl, but requires glibc

It might be a good idea to add D to the toolchain, for educational purposes

Hmm this is the LLVM D compiler
https://github.com/ldc-developers/ldc/releases

Toolchain platform name

When I build aarch64 toolchain the script produces "aarch64-buildroot-linux-gnu" platform name. Is this possible to fix it for the classical "aarch64-linux-gnu" ? So that tools look like "aarch64-linux-gnu-gcc" etc

ARC toolchain comes with bison that fails to relocate with relocate-sdk.sh

Both arcle-hs38--glibc--stable-2018.02-2 and arcle-hs38--glibc--bleeding-edge-2018.07-3 seem to come with a bison binary that is still looking in the original installation path for its internal files even after I've run relocate-sdk.sh:

+bison: /opt/arcle-hs38--glibc--stable-2018.02-2/share/bison/m4sugar/m4sugar.m4: cannot open: No such file or directory
+make[2]: *** [scripts/Makefile.lib:228: scripts/kconfig/zconf.tab.c] Error 1
+make[1]: *** [Makefile:492: tb100_defconfig] Error 2
+make: *** [Makefile:148: sub-make] Error 2

and

+bison: /opt/arcle-hs38--glibc--bleeding-edge-2018.07-3/share/bison/m4sugar/m4sugar.m4: cannot open: No such file or directory
+make[2]: *** [scripts/Makefile.lib:228: scripts/kconfig/zconf.tab.c] Error 1
+make[1]: *** [Makefile:492: nsim_hs38be_defconfig] Error 2
+make: *** [Makefile:148: sub-make] Error 2

As far as I can tell, the other toolchains that I tried didn't come with bison (or flex for that matter) at all. So just removing bison would 'fix' this and make the ARC toolchains consistent with the other toolchains.

musl 1.2.2 builds

https://musl.libc.org/releases.html

Musl 1.2.2 was released basically 1 year ago January 2021 with several fixes as well as CVE fixes. All the toolchains currently listed only use musl 1.2.0.

Are there any plans to add musl 1.2.2? Anyway that I could help with such an effort or build it on my own?

build-toolchain.sh doesn't flag all supported options

Currently, the generated fragments that are supposed to reflect the options that are enabled are overlooking BR2_GCC_ENABLE_OPENMP, BR2_TOOLCHAIN_BUILDROOT_DLANG, and possibly others.

https://github.com/bootlin/toolchains-builder/blob/master/build-toolchain.sh#L166

quick fix:

    if grep -q "BR2_GCC_ENABLE_OPENMP=y" ${configfile}; then
        echo "BR2_TOOLCHAIN_EXTERNAL_OPENMP=y" >> ${fragment_file}
    else
        echo "# BR2_TOOLCHAIN_EXTERNAL_OPENMP is not set" >> ${fragment_file}
    fi
    if grep -q "BR2_TOOLCHAIN_BUILDROOT_DLANG=y" ${configfile}; then
        echo "BR2_TOOLCHAIN_EXTERNAL_DLANG=y" >> ${fragment_file}
    else
        echo "# BR2_TOOLCHAIN_EXTERNAL_DLANG is not set" >> ${fragment_file}
    fi

why not have mips64-n64

below is my machine and binary information

#uname -a
Linux usm.secondary.10.113.58.152 4.19.0-loongson-3-server #20211013 SMP PREEMPT Uos 4.19.0-eagle Wed Oct 13 15:36:26 CST 2 mips64 GNU/Linux

#file gzip
gzip: ELF 64-bit LSB shared object, MIPS, MIPS64 rel2 version 1 (SYSV), dynamically linked, interpreter /lib64/ld.so.1, BuildID[sha1]=396518ffad8b2bc976f82ebc9b398d7d2b354faf, for GNU/Linux 3.2.0, stripped

2021.11-1: mips64-n32 issues with glibc > 34

An annoying bug has been found on glibc > v34: #29069.

Issue:

built a rootfs with the bootlin toolchain for mips64-n32 (2021.11-1)
boot with qemu (/usr/bin/qemu-system-mips64 -machine malta)
in the shell: mkdir -m 777 -p /scratch => mkdir: cannot change permissions of '/scratch': Not a directory

A fix has been backported to every versions (v34 and after) that fix the issue: 78fb88827362fbd2cc8aa32892ae5b015106e25c.

Rebuilding the 2021.11-1 toolchains with the updated glibc 34 would fix the issue.

Binutils 2.37 issue with bleeding-edge toolchain 2021.11-1

Hello,

The bleeding-edge toolchain 2021.11-1 fail to build qt5webengine due to an Binutils 2.37 issue.

See:
https://git.buildroot.net/buildroot/commit/?id=40f7b0bb6b91400b9e1fc60f410c9cdcbd1998ab

Prebuilt toolchains based on Binutils 2.37 must be rebuild with this fix.

Big Endian Support?

I'm trying to get arm32 big endian working and I'm getting lots of errors when compiling. Is there some additional configuration that I'll need to do get arm32BE running?

No LLVM? No Zig? No Clang?

Document usage

Sorry if I just don't know what I'm doing, but could you please document usage? Do you copy it into /? Do you chroot in?

Add a more generic x86-64 toolchain

Hello.

I tried the bootlin corei7 toolchain
with buildroot. It built the unfunctional
(on my old AMD CPU) system.
Then I did this:
BR2_TARGET_OPTIMIZATION="-march=x86-64 -mtune=generic"
and got the system half-working:
kernel is OK, some early-boot
user-space is OK, but most things
crash with invalid opcode exception.

I suspect the problem is that
libraries (like libgcc perhaps) are
already over-optimized in the bootlin
toolchain.
Would it be an option to rebuild
the bootlin toolchain with the "generic"
x86_64 CPU support, and keep using
the SSE optimizations by default only
for compiled code? Then it will be
possible to override with optimization
flags.

/build # ./armv7-eabihf--musl--bleeding-edge-2020.02-2/bin/arm-linux-cc -v
/bin/sh: ./armv7-eabihf--musl--bleeding-edge-2020.02-2/bin/arm-linux-cc: not found

But the file is there:

/build # ls -l ./armv7-eabihf--musl--bleeding-edge-2020.02-2/bin/arm-linux-cc
lrwxrwxrwx    1 root     root            17 Apr  4 17:31 ./armv7-eabihf--musl--bleeding-edge-2020.02-2/bin/arm-linux-cc -> toolchain-wrapper

My host is x86_64:

/build # uname -m
x86_64
/build # cat /etc/os-release 
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.11.5
PRETTY_NAME="Alpine Linux v3.11"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"

Any ideas on what is wrong?