Until commit "arch/Config.in.sh: fixup MMU selection" in this series,
SH2A could either be used with BR2_USE_MMU disabled or BR2_USE_MMU
enabled.
The later made absolutely no sense, since SH2A does not have a MMU:
MMU support was introduced starting from SH3 according to
https://en.wikipedia.org/wiki/SuperH#SH-3
Also, since commit 22d5501e03 ("arch:
tidy up binary formats config"), which was merged in Buildroot
2015.05, the architecture tuple used when BR2_sh2a=y and BR2_USE_MMU
disabled is sh2a-buildroot-uclinux-uclibc, and this was already
unsupported back in the days of Buildroot 2015.08 and binutils 2.24,
causing the build to fail with:
*** BFD does not support target sh2a-buildroot-uclinux-uclibc.
just like it fails to build today with recent version of binutils.
So, this has been broken since 2015.08, and nobody complained. SH2A is
seldom used, so it's time to kill it.
It is worth mentioning that there had been an attempt at resurrecting
SH2 support around 2015 (see https://lwn.net/Articles/647636/) as part
of the J2 core. This effort led to the addition of FDPIC support for
SH2A in the musl C library (and therefore proper ELF binaries, with
shared libraries), but that was never supported in Buildroot. Now that
the J2 project is essentially dead, there is no reason to bother with
this.
Fixes:
http://autobuild.buildroot.net/results/63d01d33ae30f86b63b9f42a9fea116f2f3e9005/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Gcc bug 99140 exhibits with gcc versions:
- up to 7.x
- 9.x
- 10.x
and doesn't show up with gcc versions:
- 8.x
- 11.x
then moving BR2_TOOLCHAIN_GCC_AT_LEAST_9 to BR2_TOOLCHAIN_GCC_AT_LEAST_10
makes gcc version 9 set as working but it's not. So let's back substitute
BR2_TOOLCHAIN_GCC_AT_LEAST_10 with BR2_TOOLCHAIN_GCC_AT_LEAST_9.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Convert BR2_TOOLCHAIN_EXTERNAL_PATH to an absolute path when used.
Otherwise the symbolic links to the external toolchain binaries are
not installed in host/bin when BR2_TOOLCHAIN_EXTERNAL_PATH is relative.
This happens because TOOLCHAIN_EXTERNAL_INSTALL_WRAPPER
changes directory into host/bin to create the symbolic links.
From there the tools are no longer found via the relative path and
a single symbolic link host/bin/$(prefix)-* is created instead.
Although relative paths sounds like something less than ideal to put in
a Buildroot configuration, it's actually rather typical to put the
buildroot sources as a submodule (or subdirectory) of custom sources
(either in a BR2_EXTERNAL or not), in which case the relative path is
well-defined.
Signed-off-by: Juergen Stuber <juergen@jstuber.net>
Reviewed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Gcc bug 99410 reappeared in gcc 10.x while building belle-sip, but it's
fixed on gcc 11.x, so let's update bug conditions.
Fixes:
http://autobuild.buildroot.net/results/846597f3573d3b0d52e80627a9577d14b9348547/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The OpenRISC toolchains have been rebuilt once again, this time with
the _REENTRANT fixed merged in commit
98e39dc80e ("package/gcc: define
_REENTRANT for OpenRISC when -pthread is passed")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In GCC6 the compiler was made smarter to omit the flag
-fdebug-prefix-map from the DWARF DW_AT_producer section[1]. That flag
contains the absolute path '$(BASE_DIR)' which breaks reproducibility.
Prior to GCC6 however, the only way to omit the flag is to use
-gno-record-gcc-switches which omits all flags.
[1] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=266cc0c181549c2fb6b50f8f26213cdc89101026
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
[Arnout: invert condition to ifeq (,) instead of ifneq (,y)]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
In GCC8 the flag -ffile-prefix-map handles cleaning up both the __FILE__
macros and the debug info paths. In GCC7 or below we are manually
handling the __FILE__ macros, but not debug info paths. Use
-fdebug-prefix-map to clean them up. This option exists since GCC 4.3.0,
which is our minimal supported GCC version.
See for more detail: https://reproducible-builds.org/docs/build-path/
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The Bootlin toolchains for the OpenRISC architecture have been rebuilt
with the fix for binutils bug 28735, so let's update their definition
in Buildroot.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Binutils bug 21464 is not present anymore in Buildroot so let's remove it
and its depends on in libgeos and postgis packages.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Following the releases of 2021.11 Bootlin toolchains, this commit
represents the result of re-running the gen-bootlin-toolchains script.
The only part that isn't auto-generated are the contents of
Config.in.legacy, which account for the replacement of the RISC-V LP64
toolchain by RISC-V LP64D toolchains.
The complete set of runtime test cases was verified on Gitlab CI:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/437767674
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
`which' has been discontinued after 2.21 release in 2015 due this (git
repository is empty [1]) and version shipped in Debian produces warning
[2]:
/usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.
`command is POSIX [3] and supported on all common shells (bash, zsh,
dash, busybox sh, mksh).
Patch tested on dash as the default shell.
[1] https://git.savannah.gnu.org/cgit/which.git
[2] 3a8dd10b45
[3] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The gdbinit supplied by Buildroot does two things:
A. specify the sysroot where gdb can find shared libraries
B. mark the sysroot as a 'safe path' for its auto-load feature, to make sure
that pretty printers for libstdc++.so are added automatically (see commit
6fb3216a80)
When debugging a core file, and the gdbinit file is specified via '-x'
rather than '-ix', then the order of these settings matters: If you first
set the sysroot, then gdb will immediately start finding the shared
libraries it needs for the core file, detect libstdc++ and its associated
libstdc++-gdb.py file, then give a big warning about safe paths:
warning: File ".../i686-buildroot-linux-gnu/sysroot/lib/libstdc++.so.6.0.24-gdb.py"
auto-loading has been declined by your `auto-load safe-path' set
to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path .../i686-buildroot-linux-gnu/sysroot/lib/libstdc++.so.6.0.24-gdb.py
line to your configuration file "/home/me/.gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/home/me/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
info "(gdb)Auto-loading safe path"
and the pretty printing code is not loaded. This is because the second
line from the gdbinit file was not yet parsed at this point.
By changing the order (first configuring the safe path, then setting the
sysroot), this issue does not appear and everything is as expected.
Note that when '-ix' were used instead of '-x' to pass the gdbinit file to
gdb, then the order would not matter, because the entire gdbinit file would
be parsed before considering the core file.
However, even though the Buildroot manual now suggests '-ix', users may not
have noticed this change and continue to use '-x'.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Update to gcc 10.3, gdb 10.2, binutils 2.36.1, glibc 2.33.
Remove BR2_TOOLCHAIN_HAS_NATIVE_RPC since the support for obsolete
RPC was finally dropped in glibc in 2.32 (2020-08-04).
See "Release Note":
https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads#
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Update to gcc 10.3, gdb 10.2, binutils 2.36.1, glibc 2.33.
Remove BR2_TOOLCHAIN_HAS_NATIVE_RPC since the support for obsolete
RPC was finally dropped in glibc in 2.32 (2020-08-04).
See "Release Note":
https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads#
Tested with qemu_aarch64_virt_defconfig.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Update to gcc 10.3, gdb 10.2, binutils 2.36.1, glibc 2.33.
Remove BR2_TOOLCHAIN_HAS_NATIVE_RPC since the support for obsolete
RPC was finally dropped in glibc in 2.32 (2020-08-04).
See "Release Note":
https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads#
Tested with qemu_arm_vexpress_defconfig.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reorder gcc bugs by number
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Some 3rd party vendor toolchains have multiple files which match
these glob patterns. In this case, the shell script failed.
Switching to use find and xargs solves the issue.
Signed-off-by: Jonah Petri <jonah@petri.us>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Some 3rd party vendor toolchains have multiple files which match
these glob patterns. In this case, the shell script failed.
Switching to use find and xargs solves the issue.
Signed-off-by: Jonah Petri <jonah@petri.us>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Gcc bug 99140 has been fixed on gcc 8.x but reappeared on gcc 9.x while
it's been fixed on gcc 10.x+. So let's update
BR2_TOOLCHAIN_HAS_GCC_BUG_99140 accordingly.
Fixes:
http://autobuild.buildroot.net/results/c55/c55f50a8d657695f0d5492c32efa666254cd7f99/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This bug has been fixed upstream and backported to buildroot binutils
package. So let's remove it from toolchain/Config.in and from packages
that are affected by it:
- libgeos
- postgis
- protobuf
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gdb can automatically load certain files as described in [1]. Such files
could install pretty-printers for complex data structures.
libstdcxx (C++ standard library) provided by gcc, is one example of a
library for which such auto-load file is available. But there are other
examples too, like libglib2.
However, gdb will only auto-load files if the file is located in one of the
locations treated as 'safe'. The Buildroot sysroot is not by default in that
list.
Provide a better debugging experience by adding the sysroot to the 'safe'
list, via the gdbinit file prepared by Buildroot.
[1] https://sourceware.org/gdb/onlinedocs/gdb/objfile_002dgdbdotext-file.html
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gcc installs a libstdcxx-...so-gdb.py file that gdb will load automatically
when it loads libstdcxx.so, via the mechanism described at [1].
However, the auto-load file installed by gcc contains hardcoded paths
referring to the location where the (external) toolchain was built, which
are normally not available.
Fix up the paths in the load file so that the pretty printers can be loaded
automatically.
Note that gdb will only auto-load the file if its location is marked as
'safe'. A subsequent commit will take care of that.
Technically, there could be more than one load file, e.g. in lib and
usr/lib, so fix them all. This was for example observed in
BR2_TOOLCHAIN_EXTERNAL_ARM_AARCH64.
In a very specific case with a local custom toolchain, there were actually
two 'python' directories, which would break the sed command, so arbitrarily
limit to the first one encountered.
[1] https://sourceware.org/gdb/onlinedocs/gdb/objfile_002dgdbdotext-file.html
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch allows to use an external toolchain based on gcc 11.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
In order to add gcc 11 support for internal and external toolchain in
follow-up commits, introduce BR2_TOOLCHAIN_GCC_AT_LEAST_11 symbol.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
On Nios II binutils it still present ld bug 27597 leading to a package
libgeos to fail building:
c053b9e191/
The bug was already reported and it's been updated:
https://sourceware.org/bugzilla/show_bug.cgi?id=27597
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19615 and
BR2_TOOLCHAIN_HAS_BINUTILS_BUG_20006 options were last selected by the
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_AMD64 toolchain, but this
toolchain has been removed as part of commit
d87e114a8f in August 2020.
It's time to get rid of those two options that are never enabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The OpenRISC binutils is affected by a linker bug (binutils bug 21464)
for which no workaround exists. This causes build breakage in a number
of packages, so this commit introduces a
BR2_TOOLCHAIN_HAS_BINUTILS_BUG_21464 option to identify this bug. As
all binutils versions are affected, this option is true whenever the
configuration targets OpenRISC.
The bug was already reported and it's been recently updated:
https://sourceware.org/bugzilla/show_bug.cgi?id=21464
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since gcc version 10.x bug 60620 doesn't show anymore, so let's make it
enabled up to versino 10.x excluded.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The Bootlin PowerPC 440 FP toolchain was rebuilt in version 2020.08-2,
which is rebased on Buildroot 2020.08.3 as that includes a fix for
SecurePLT support.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes build error
output/host/opt/ext-toolchain/bin/../lib/gcc/aarch64-amd-linux-gnu/4.9.1/../../../../aarch64-amd-linux-gnu/bin/ld:
cannot find -latomic
using this defconfig
BR2_aarch64=y
BR2_TOOLCHAIN_EXTERNAL=y
BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_AARCH64=y
BR2_PACKAGE_OPENSSL=y
libopenssl is only used here as an example: all packages adding -latomic
if BR2_TOOLCHAIN_HAS_LIBATOMIC=y are broken, like dav1d, ffmpeg, gnutls,
kodi and vlc.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Support for obsolete RPC was dropped in glibc 2.14 (2011-05-31), then
reinstated and marked obsolete in glibc 2.16 (2012-06-30), and finally
dropped for good in 2.32 (2020-08-04), which we are about to start
using.
In preparation for that, drop the usage of obsolete RPC support in
glibc.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: add a bit of history]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Starting with glibc-2.32, the RPC code has been removed from
glibc [0], and it is not possible anymore to enable it, even
with the --enable-obsolete-rpc configure option (which was
also removed).
riscv32 and arc both use a glibc 2.32+ so do not forcefully
enable native RPC for them.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The RISC-V 32-bit toolchain is using a recent glibc version that no
longer has RPC support. Thanks to the change in
gen-bootlin-toolchains, this is now properly detected.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/849510531
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
While testing Buildroot on a Cortex-A5 that doesn't provide NEON, we
found out that a system generated with the ARM toolchain from Arm
didn't boot. It turns out that this ARM toolchain is built with:
--with-arch=armv7-a --with-fpu=neon --with-float=hard --with-mode=thumb
So, it uses NEON as its FPU, which means it can only work on CPU cores
that have NEON support. This commit adds the appropriate dependency to
the toolchain-external-arm-arm package, and adjusts the Config.in help
text accordingly.
While at it, it also drops the part of the Config.in help text that
says the code is tuned for Cortex-A9, as it is not the case: it was
the case for the Linaro toolchain (built with --with-tune=cortex-a9),
but not for the ARM toolchain, for which no specific --with-tune is
passed.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The commit [1] enabled riscv32 and riscv64 for uClibc-ng
internal toolchain backend but only riscv64 is curently
supported by uClibc-ng.
The initial patch [2] from Mark Corbin is only about riscv64.
Remove riscv32 from uClibc-ng supported architecture list.
Fixes:
https://gitlab.com/buildroot.org/buildroot/-/jobs/830981656
[1] 209a082478
[2] bd9810e176
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Bootlin toolchains in version 2020.08-1 have just been released, so
let's update the toolchain-external-bootlin package to those new
toolchains.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
uclibc-ng supports the RISC-V architecture since version 1.0.31, so
let's allow selecting this C library when RISC-V is used.
There was a previous attempt in commit
bd9810e176, which was reverted in
e7d631c0df, due to uClibc-ng not
implementing the __riscv_flush_icache() which is needed by
gcc. However this function has been implemented in upstream uClibc-ng
as of 1.0.35, so we can now safely re-enable uClibc-ng on RISC-V.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit wires-up the toolchain-external-bootlin package into
Buildroot by:
- Adding
toolchain/toolchain-external/toolchain-external-bootlin/Config.in,
which is not generated by the bl-toolchains-gen script as it is a
static file that does not depend on the list and characteristics of
available Bootlin toolchains.
- Including that file, as well as the Config.in.options file, from
toolchain/toolchain-external/Config.in.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Titouan Christophe <titouan.christophe@railnova.eu>
Tested-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit adds the contents of the
toolchain/toolchain-external/toolchain-external-bootlin/ files
generated by bl-toolchains-gen, unmodified.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Titouan Christophe <titouan.christophe@railnova.eu>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This toolchain uses an old gcc 6.2.0 compiler (not even the latest gcc
from the 6.x series), which fails to build the recent Boost
package. Since newer versions of this toolchain are no longer made
publicly available from Mentor Graphics, our only option is to drop
the toolchain.
Fixes:
http://autobuild.buildroot.net/results/10edaed22c15b9d0f7de187085aeebc96e5ebe6c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This reverts commit bd9810e176. Indeed,
while uClibc-ng has support for RISC-V 64-bit, this support lacks the
__riscv_flush_icache() function call, which is used by some GCC
builtins used for example in libffi.
Due to this missing __riscv_flush_icache(), anything that links
against libffi fails to build:
/home/test/autobuild/run/instance-0/output-1/host/bin/riscv64-buildroot-linux-uclibc-gcc -o gobject/gobject-query gobject/gobject-query.p/gobject-query.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-O1 -Wl,--start-group glib/libglib-2.0.so.0.6400.4 gobject/libgobject-2.0.so.0.6400.4 -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../glib:$ORIGIN/' -Wl,-rpath-link,/home/test/autobuild/run/instance-0/output-1/build/libglib2-2.64.4/build/glib -Wl,-rpath-link,/home/test/autobuild/run/instance-0/output-1/build/libglib2-2.64.4/build/gobject
/home/test/autobuild/run/instance-0/output-1/host/lib/gcc/riscv64-buildroot-linux-uclibc/9.3.0/../../../../riscv64-buildroot-linux-uclibc/bin/ld: /home/test/autobuild/run/instance-0/output-1/host/riscv64-buildroot-linux-uclibc/sysroot/usr/lib64/libffi.so.7: undefined reference to `__riscv_flush_icache'
collect2: error: ld returned 1 exit status
Note that this commit means that
support/config-fragments/autobuild/br-riscv64-full-internal.config
will be back to using glibc as the C library, but that is OK, until
uClibc-ng is fixed to implemented __riscv_flush_icache().
This uClibc-ng issue has been reported upstream at
https://mailman.uclibc-ng.org/pipermail/devel/2020-August/002022.html.
Fixes:
http://autobuild.buildroot.net/results/ec1185ad1fd8863a3990143a0af2ace987761a27/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
We can enable uclibc for RISC-V 64 bit now that it has been
bumped from v1.0.32 to v1.0.34.
Uclibc has had basic support for RISC-V 64 bit since v1.0.31, but
shared library and TLS/NPTL support has only been available since
v1.0.33.
This update has been tested using qemu_riscv64_virt_defconfig and
the Buildroot host QEMU.
Signed-off-by: Mark Corbin <mark@dibsco.co.uk>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
For glibc 2.31.x:
- Update LICENSES file hash due to url change:
"Prefer https to http for gnu.org and fsf.org URLs"
- riscv64 does not build with kernel headers < 5.0, but upstream
has not yet comitted a single fix, neither in master nor in the
maintenance branch:
https://sourceware.org/ml/libc-alpha/2020-02/msg00018.html
For localedef 2.31.x:
- Remove upstream patch for localedef:
0003-localedef-Use-initializer-for-flexible-array-member-.patch
Note that this version bump required some patches applied on
several packages (already applied):
[Busybox] 13f2d688a2
[openssh] bad75bca31
[gcc] disable libsanitizer with gcc 7.5
See:
https://sourceware.org/legacy-ml/libc-announce/2020/msg00001.html
Tested by toolchain builder:
https://gitlab.com/kubu93/toolchains-builder/pipelines/129551000
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When using precompiled headers, changing any macros defined on the
command line will invalidate the precompiled header. With
toolchain-wrapper adding __DATE__ and __TIME__, any commits to Buildroot
will invalidate incremental builds regardless of whether the precompiled
header actually uses those values (affecting _OVERRIDE_SRCDIR).
GCC-7 and later support SOURCE_DATE_EPOCH and use it to define __DATE__
and __TIME__ internally, avoiding any impact on precompiled headers.
Disable the custom handling in toolchain-wrapper if GCC is version 7 or
newer.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch allows to use custom external toolchains based on gcc 10.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In order to add gcc 10 support for internal and external toolchain in
follow-up commits, introduce BR2_TOOLCHAIN_GCC_AT_LEAST_10 symbol.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
On some legacy systems, the X11 headers and libs are in /usr/X11R66/include
and /usr/X11R66/lib, and of course, some packages are trying to be smart
and use those paths (even when they do not exist).
Add those to the list of unsafe paths to check in the toolchain wrapper.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
A gcc compiler, which was configured with
--with-gcc-major-version-only, will only return a single
number. (debian does this for example).
A simple modification allows the check to work with both
single numbers (eg. '9') and full versions (eg. '9.2.1').
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
From: Julien Boibessot <julien.boibessot@armadeus.com>
It could be usefull to have ldd on the target so install it.
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
[Sébastien: add commit message]
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Config option was placed at the wrong position.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
make-4.3 shipped with a backward incompatible change in how sharp signs
are handled in macros. Previously, up to make 4.2, the sharp sign would
always start a comment, unless backslash-escaped, even in a macro or a
fucntion call.
Now, the sharp sign is no longer starting a comment when it appears
inside such a macro or function call. This behaviour was supposed to be
in force since 3.81, but was not; 4.3 fixed the code to match the doc.
As such, use of external toolchains is broken, as we use the sharp sign
in the copy_toolchain_sysroot macro, in shell variable expansion to
strip off any leading /: ${target\#/}.
Fix that by applying the workaround suggested in the release annoucement
[0], by using a variable to hold a sharp sign.
[0] https://lists.gnu.org/archive/html/info-gnu/2020-01/msg00004.html
Signed-off-by: Yaroslav Syrytsia <me@ys.lc>
[yann.morin.1998@free.fr:
- move the SHARP_SIGN definition out of Makefile and into support/
- expand the commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
[yann.morin.1998@free.fr:
- bump to 5.5.13
- rebase on top of master
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The external toolchain configure step calls the
check_kernel_headers_version make function to compare the kernel
headers version declared in the configuration with the actual kernel
headers of the toolchain.
This function takes 4 arguments, but due to a missing comma what
should be the first two arguments are both passed into the first
argument. Due to this, when check_kernel_headers_version does:
if ! support/scripts/check-kernel-headers.sh $(1) $(2) $(3) \
$(if $(BR2_TOOLCHAIN_HEADERS_LATEST),$(4),strict); \
Then:
$(1) contains "$(BUILD_DIR) $$(call toolchain_find_sysroot,$$(TOOLCHAIN_EXTERNAL_CC))"
$(2) contains "$$(call qstrip,$$(BR2_TOOLCHAIN_HEADERS_AT_LEAST))"
$(3) contains "$$(if $$(BR2_TOOLCHAIN_EXTERNAL_CUSTOM),loose,strict))"
So from the point of view of check-kernel-headers.sh, it already has
four arguments, and therefore the additional argument passed by:
$(if $(BR2_TOOLCHAIN_HEADERS_LATEST),$(4),strict); \
is ignored, defeating the $(BR2_TOOLCHAIN_HEADERS_LATEST) test.
The practical consequence is that a toolchain that has 5.4 kernel
headers but declared as using 5.3 kernel headers does not abort the
build, because the check is considered "loose" while it should be
"strict".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit adds a user-visible option
BR2_TOOLCHAIN_EXTERNAL_HAS_SSP_STRONG, which will allow the user to
indicate if the custom external toolchain does or does not have
SSP_STRONG support. Depending on this, the user will be able to use
(or not) the BR2_SSP_STRONG option.
Checking if what the user said is true or not about this is already
done in toolchain/toolchain-external/pkg-toolchain-external.mk:
$$(Q)$$(call check_toolchain_ssp,$$(TOOLCHAIN_EXTERNAL_CC),$(BR2_SSP_OPTION))
If the user selects BR2_SSP_STRONG, this will check if
-fstack-protector-strong is really supported.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This will allow toolchain to indicate if they support
-fstack-protector-strong or not.
Whenever the gcc version is >= 4.9, we always have SSP_STRONG support
if we have SSP support. However, some toolchains older than gcc 4.9
might have backported SSP_STRONG support, which is why we cannot rely
just on BR2_TOOLCHAIN_GCC_AT_LEAST_4_9.
Having this "default" value allows to avoid adding a "select
BR2_TOOLCHAIN_HAS_SSP_STRONG" in the internal toolchain logic plus in
almost external toolchains. But it allows custom external toolchains
that are pre-4.9 to potentially declare that they support strong SSP.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Most, but not all our C code follows the Linux kernel code style (as
documented in Documentation/process/coding-style.rst). Adjust the few
places doing differently:
- Braces:
..but the preferred way, as shown to us by the prophets Kernighan
and Ritchie, is to put the opening brace last on the line
- Spaces after keywords:
Use a space after (most) keywords
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
When Buildroot is released, it knows up to a certain kernel header
version, and no later. However, it is possible that an external
toolchain will be used, that uses headers newer than the latest version
Buildroot knows about.
This may also happen when testing a development, an rc-class, or a newly
released kernel, either in an external toolchain, or with an internal
toolchain with custom headers (same-as-kernel, custom version, custom
git, custom tarball).
In the current state, Buildroot would refuse to use such toolchains,
because the test is for strict equality.
We'd like to make that situation possible, but we also want the user not
to be lenient at the same time, and select the right headers version
when it is known.
So, we add a new Kconfig blind option that the latest kernel headers
version selects. This options is then used to decide whether we do a
strict or loose check of the kernel headers.
Suggested-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Vincent Fazio <vfazio@xes-inc.com>
[yann.morin.1998@free.fr:
- only do a loose check for the latest version
- expand commit log
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Vincent Fazio <vfazio@xes-inc.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The oldest toolchain we test in the autobuilders is the Sourcery ARM
toolchain which is GCC 4.8 and kernel headers 3.13. Therefore, it is
likely that we're missing the required _AT_LEAST dependencies to exclude
packages that don't build with older GCC/headers.
Add a comment to the custom external toolchain that warns when an
untested GCC or kernel headers version is selected.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
