bootlin / toolchains-builder Goto Github PK
View Code? Open in Web Editor NEWHome Page: http://toolchains.free-electrons.com
Home Page: http://toolchains.free-electrons.com
Can you please made a toolchain for armv7 softfp with clib 2.24?
I have this kind of board, now use armv5 toolchain.
T.I.A.
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
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.
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
Testing x86-i686--glibc--stable-2021.11-1.tar.bz2
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
https://unix.stackexchange.com/questions/9705/can-new-glibc-versions-be-used-with-an-old-kernel
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?
Would it be possible to read the news section as RSS feed?
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/.
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.
loongarch64 is a new RISC architecture which has recently been supported by the open source community.
On :
An overview of the development status of loongarch64 in the open source community can be seen here: https://areweloongyet.com/
Running configuration tests
...
Checking for machine tuple...
aarch64-buildroot-linux-gnu
test config.qtbase.tests.machineTuple succeeded
Checking for valid makespec...
Info: creating stash file /home/sergey/Projects/orpaltech/qt-build/qt5/build/linux-sun50i-a64-drm-g++/qtbase/config.tests/.qmake.stash
/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
Instead of rewinding the cursor and removing the previous character, each backspace appends a space to the cmdline.
$ 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.)
(Haven't tested others.)
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.
Can we view the pipelines somewhere to see what commands are executed, or is there some other way to reproduce a build of a toolchain locally?
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.
is there any plan to create toolchains for x86 host architecture?
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!
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.
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.
In the bin
folder, there is no riscv64-buildroot-linux-gnu-gdb
.
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
With the availability of ARM-based Macs, Chromebooks, Raspberry Pis, etc., it would be useful to have the toolchains released for arm64 hosts.
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.
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.
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.
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.
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.
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.
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!
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
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?
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?
I've downloaded the toolchain and when I try to use it I get the following:
/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?
Hey, thx for your awesome work!
This tool was made possible because of you https://github.com/nongiach/arm_now
We are actively using 405, e300 and e500v2. Would be great if you could add support for those.
An annoying bug has been found on glibc > v34: #29069.
Issue:
/usr/bin/qemu-system-mips64 -machine malta
)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.
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?
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
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.
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
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.