With the introduction of ARM FDPIC support, we need to make sure that
the existing ARM FLAT external toolchains are not made
visible/available when ARM FDPIC is selected. This commit updates the
gen-bootlin-toolchains script to take this into account.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit updates the Bootlin external toolchain package to use the
recently released 2024.05 toolchains.
Notable changes:
- Tarballs are now xz-compressed instead of bz2-compressed
- We have new toolchains: RISC-V 32-bit glibc stable, RISC-V 32-bit
uClibc, S390 uClibc, and the Sparc V8 is finally updated
All unit tests are passing, except 2 (see below):
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/1417551794/builds
The two tests that are not passing are the RISC-V 32-bit musl:
https://gitlab.com/tpetazzoni/buildroot/-/jobs/7607519955https://gitlab.com/tpetazzoni/buildroot/-/jobs/7607519954
This is due to a bug in Busybox, and already existed prior to this
toolchain update.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Until now only one option was shown, and we were automatically
selecting the ARC700/ARChs and LE/BE toolchains based on the
architecture selection. However now, Synopsys offers glibc/uClibc
toolchains, and we can't decide that automatically, so let's add an
explicit choice for the user to chose between the different variants
of Synopsys toolchains available.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: fix glibc toolchain prompt to mention ARC HS]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
similar to previous problems with nios2 and not-available atomic ints
the build for Boost.Atomics also fails for ARC Targets which don't
have the ATOMICS_EXT flag set.
according to [0] "Boost.Atomic has a hard requirement of the native
atomic operations on bytes". The same tests mentioned there fail for
ARC without the atomic extension.
Disable BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS for BR2_arc
without BR2_ARC_ATOMIC_EXT.
Fixes:
http://autobuild.buildroot.net/results/4ca54a85672d7b9328b1909b457e548c6032a493
[0] https://github.com/boostorg/atomic/issues/42#issuecomment-734130348
Signed-off-by: Michael Nosthoff <buildroot@heine.tech>
[Arnout: add to BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS
instead of updating all packages]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
make "gcc --help -v" display all the options, some packages depend on this
https://bugs.busybox.net/show_bug.cgi?id=15231
Signed-off-by: Sagi Mor <sagimor6@gmail.com>
[Arnout: move the handling to the beginning and directly call execv]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
This patch allows to use an external toolchain based on gcc 14.
Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr>
Tested-by: Vincent Stehlé <vincent.stehle@arm.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Update BR2_TOOLCHAIN_HAS_LIBATOMIC dependencies to avoid the following
build failure with libopenssl and
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7M_UCLIBC_STABLE:
/home/buildroot/autobuild/run/instance-2/output-1/host/opt/ext-toolchain/arm-buildroot-uclinux-uclibcgnueabi/bin/ld.real: ./libcrypto.a(libcrypto-lib-threads_pthread.o): in function `CRYPTO_atomic_or':
threads_pthread.c:(.text+0xfa): undefined reference to `__atomic_is_lock_free'
libatomic is available since gcc 4.8, when thread support is enabled.
However, the gcc logic in libatomic/configure.tgt does not recognize
"uclinux" as a valid OS part of the target tuple, and therefore it
does not build libatomic. The "uclinux" part of the tuple is used by
Buildroot when BR2_BINFMT_FLAT=y [1]. This broken logic has only been
fixed for arm since gcc 10.1.0 [2].
Indeed, bootlin armv7m is an uclibc toolchain compiled with atomic
support through libatomic.
[1] https://git.buildroot.net/buildroot/commit/?id=b3d1fb26dcadd8c570e2c415ce05398ecc810b32
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b1e21e5a5d19b436f948710e09157c5b3244f541
Fixes:
- http://autobuild.buildroot.org/results/d25e898f9715bf6a21284807361a57735a7a2e1d
- http://autobuild.buildroot.org/results/e37ed5ad6ba41d610bffe9c234f699e203ef5069
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In order to add gcc 14 support in follow-up commits, introduce
BR2_TOOLCHAIN_GCC_AT_LEAST_13 symbol.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Binutils bug 27597 is not present anymore in Buildroot so let's remove it.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
This toolchain is pretty old and unlikely used. It's also affected by
binutils bug 27597, so let's remove it.
Remove BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII from pixman package.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[Romain: remove BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_NIOSII]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Note: this commit only deals with glibc and its internal libcrypt (or
lack thereof); other C libraries, musl and uClibc-NG, are not considered.
libcrypt from glibc has been deprecated for a long time, and it has now
been entirely dropped with glibc 2.39. Now, packages that need crypt(3)
features need to explicitly depend on the libxcrypt pacakge.
However, the set of files installed both by glibc and libxcrypt is not
empty:
glibc libxcrypt
/usr/include/crypt.h /usr/include/crypt.h
/usr/lib/libcrypt.a /usr/lib/libcrypt.a
/usr/lib/libcrypt.so /usr/lib/libcrypt.so
/lib/libcrypt.so.1
/lib/libcrypt-2.23.so
/usr/lib/libcrypt.so.2
The two libraries have different SO_NAME, so they do not conflict on the
library filename. However, the .so synlink is present in both, and thus
conflicts. The header and the static library also conflict.
So, the situation is that, with a glibc 2.39 or later, packages have to
use libxcrypt, which is a drop-in replacement. With glibc 2.38 or
earlier, they can use either.
Since we already bumped to glibc 2.39 for the internal toolchain, we
have already converted quite a few packages to use libxcrypt. That works
well with an internl toolchain, because glibc does not install the
conflicting files.
However, for external toolchains, we may very well end up in three
situations:
- a glibc 2.39 or later, without libcrypt
- a glibc 2.39 or later, without libcrypt, but with libxcrypt [0]
- a glibc 2.38 or earlier with libcrypt
In the first case, all is OK and we are in a situation similar to the
internal toolchain, but in the latter two cases, we end up with a
conflict.
We could introduce BR2_TOOLCHAIN_EXTERNAL_HAS_LIBCRYPT os something
along those lines, but this is going to be a bit complex on packages,
which would have to select LIBXCRYPT if GLIBC && !_HAS_LIBCRYPT.
So, to simplify things, we want to get the external toolchains into a
situation similar to the internal one, where libcrypt is not provided by
the toolchain; packages have to select libxcrypt for glibc toolchains,
without having to care whether this is an internal or external toolchain
or some more complex conditions.
So, we remove from staging whatever could be used to compile and link
with libcrypt. We however keep the SO_NAME file, if it exists, and we
also install it in target/, for those pre-built binaries that may be
linked with it [1]. The glibc SO_NAME has always been libcrypt.so.1, so
this is what we copy exactly, to avoid copying the libxcrypt one, which
is libcrypt.so.2.
[0] that could happen if a toolchain provider tried to be helpful and
suplies a toolchain with libxcrypt to be trasnparent to users, in which
case that would conflict with ours...
[1] if such a prebuilt binary (executable or library) is used with a
glibc 2.39 or later toolchain, it will obviously not work at all.
libxcrypt is supposed to be a drop-in replacement for glibc's libcrypt,
so we could look into symlinking libcrypt.so.1 to libcrypt.so.2. In a
later patch, maybe...
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Although -Wmain-return-type is not considered as error (unlike
-Wimplicit-int), but just a warning, let's fix it for the future.
<stdin>:1:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2024.02 Bootlin toolchains have been released, so let's update the
support in Buildroot. Notable changes:
- Bleeding edge toolchains now use binutils 2.42, and stable
toolchains use binutils 2.41. This fixes binutils bug 27597
for both.
- glibc has been updated to 2.39
- musl has been updated to 1.2.5, which brings 32-bit RISC-V
support. Due to this, 2 new toolchain variants are added: 32-bit
RISC-V stable, 32-bit RISC-V bleeding edge.
- Bleeding edge toolchains now use 5.15 kernel headers, and stable
toolchains now use 4.19 kernel headers
- Fortran support has been disabled on Microblaze, as the libgfortran
build at -O2 causes an internal compiler error.
All runtime tests are passing, except the ones for the new RISC-V
32-bit musl toolchain, for which Busybox fails to build due to an
interaction between musl-specific code in Busybox and musl. This issue
has been reported:
https://www.openwall.com/lists/musl/2024/03/03/2
The runtime tests are nevertheless included, with the hope that this
issue will reasonably quickly be resolved.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Codescape mips toolchains are old (2018) and use glibc 2.20 which is not
compatible with 64-bit time_t raising the following build failure with
libselinux since commit 1c2dbcdcf0:
In file included from selinux_restorecon.c:17:0:
/home/buildroot/autobuild/instance-1/output-1/host/mipsel-buildroot-linux-gnu/sysroot/usr/include/fts.h:41:3: error: #error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
^~~~~
Fixes: 1c2dbcdcf0
- http://autobuild.buildroot.org/results/a4d38af627a42a2c55d60129787c51353d5883bf
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
codesourcery arm/aarch64 toolchains are old (2014) and use glibc
2.18/2.20 which are not compatible with 64-bit time_t raising the
following build failure with libcgroup since commit
1c2dbcdcf0:
In file included from ./libcgroup-internal.h:25:0,
from parse.y:21:
/home/buildroot/autobuild/run/instance-3/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/fts.h:41:3: error: #error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
^
Fixes: 1c2dbcdcf0
- http://autobuild.buildroot.org/results/e28f955f2b360f6e7bb231a5a3800cfbd17a23d7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Peter: add Config.in.legacy entries]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
As suggested by Thomas Petazzoni in [1], add a comment on
BR2_TOOLCHAIN_HAS_UCONTEXT to specify that this boolean will be set to
true only when a toolchain provides a full featured ucontext
implementation with ucontext_t and {get,make,set}context. As a result,
drop its selection from BR2_TOOLCHAIN_USES_MUSL to fix the following
musl build failure on php:
/home/autobuild/autobuild/instance-8/output-1/host/lib/gcc/m68k-buildroot-linux-musl/12.3.0/../../../../m68k-buildroot-linux-musl/bin/ld: Zend/zend_fibers.o: in function `zend_fiber_init_context':
zend_fibers.c:(.text+0x946): undefined reference to `getcontext'
[1]: https://patchwork.ozlabs.org/project/buildroot/patch/20230516193307.1543455-1-bernd.kuhls@t-online.de/
Fixes:
- http://autobuild.buildroot.org/results/271f9fb8bfa5ba2f74feef81e6b375b54e21cece
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
This patch adds a new virtual package for adding a bare-metal
toolchain to Buildroot. For now, it depends on nothing, so it will not
actually build anything, but it defines some options that will be
needed by the various packages that will be part of this toolchain
build process.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@amd.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
New toolchains have been released, with the following changes:
- The bleeding-edge toolchains are based on gcc 13.2, binutils 2.41,
gdb 14.1, kernel headers 5.10, glibc 2.38, musl 1.2.4 or uclibc-ng
1.0.45.
- The stable toolchains are based on gcc 12.3, binutils 2.40, gdb
13.2, kernel headers 4.14, glibc 2.38, musl 1.2.4 or uclibc-ng
1.0.45.
- The glibc version is no longer affected by CVE-2023-4911
- The gdb build has been fixed to no longer rely on uninstalled
libbfd.so and libopcodes.so libraries
- The zlib library, which was incorrectly present in the toolchain
sysroot, is gone, fixing various build failures encountered with
2023.08 toolchains.
- There are now toolchains for m68k 68xxx based on uclibc and musl in
addition to glibc, which was already supported
The careful reviewer will notice that a number of
depends on !BR2_ARCH_NEEDS_GCC_AT_LEAST_14
are being added to the toolchains that use gcc 13.x, as per
a0d2a5cfec
("support/scripts/gen-bootlin-toolchains: generate
BR2_ARCH_NEEDS_GCC_AT_LEAST_X guard").
All 214 test cases were successfully run:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/1120323562
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Updated to gcc 13.2, gdb 13, binutils 2.41, glibc 2.38.
The x86_64 host variant prebuilt toolchain is built on RHEL7
(glibc 2.17) and is likely also be useable on OS versions like
RHEL8, Ubuntu 18.04 or later.
The AArch64 host variant prebuilt toolchain is built on Ubuntu 18.04
(glibc 2.27) is likely also be useable on OS versions like RHEL8,
Ubuntu 18.04 or later.
Release note:
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Updated to gcc 13.2, gdb 13, binutils 2.41, glibc 2.38.
The x86_64 host variant prebuilt toolchain is built on RHEL7
(glibc 2.17) and is likely also be useable on OS versions like
RHEL8, Ubuntu 18.04 or later.
The AArch64 host variant prebuilt toolchain is built on Ubuntu 18.04
(glibc 2.27) is likely also be useable on OS versions like RHEL8,
Ubuntu 18.04 or later.
Tested with qemu_aarch64_virt_defconfig.
Release note:
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Updated to gcc 13.2, gdb 13, binutils 2.41, glibc 2.38.
The x86_64 host variant prebuilt toolchain is built on RHEL7
(glibc 2.17) and is likely also be useable on OS versions like
RHEL8, Ubuntu 18.04 or later.
The AArch64 host variant prebuilt toolchain is built on Ubuntu 18.04
(glibc 2.27) is likely also be useable on OS versions like RHEL8,
Ubuntu 18.04 or later.
Tested with qemu_arm_vexpress_defconfig.
Release note:
https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
Signed-off-by: Antoine Coutant <antoine.coutant@smile.fr>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This commit adds a target package "gcc-final", which is a target
package responsible for installing the gcc runtime libraries to
STAGING_DIR and TARGET_DIR. This task was so far done by the host
gcc-final package.
The motivation for splitting it up into a target package is to be able
to properly handle the licensing situation of GCC, where the host part
of GCC (the compiler itself) is under GPLv3, but the runtime libraries
on the target are under GPLv3-with-exception. So far, we were not
handling at all the license of gcc.
So what this commit does is:
* Add a gcc-final target package, which is depended on by the
toolchain-buildroot package, and which depends on
host-gcc-final.
* Moves to gcc-final the logic for installing target/staging
libraries
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Currently, when verifying the configuration of a uClibc toolchain for
the presence of locale support, we check __UCLIBC_HAS_LOCALE__. It
turns out that we in fact also expect __UCLIBC_HAS_XLOCALE__ to be
defined, as without it locale_t is not defined, causing build failure
in some packages, such as libcpprestsdk:
In file included from /home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/include/cpprest/json.h:18,
from /home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/src/pch/stdafx.h:88,
from /home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/src/http/client/http_client_msg.cpp:13:
/home/thomas/autobuild/instance-0/output-1/build/libcpprestsdk-2.10.18/Release/include/cpprest/asyncrt_utils.h:317:13: error: 'locale_t' does not name a type
317 | typedef locale_t xplat_locale;
| ^~~~~~~~
As essentially our requirement for uClibc in external toolchains is
"it should match the uClibc configuration used by Buildroot for
internal toolchains", it makes sense to verify
__UCLIBC_HAS_XLOCALE__. Note that of course checking
__UCLIBC_HAS_XLOCALE__ is sufficient, as it cannot be enabled if
__UCLIBC_HAS_LOCALE isn't.
This addresses an issue with the Synopsys ARC external toolchain,
which is built with __UCLIBC_HAS_LOCALE__, but without
__UCLIBC_HAS_XLOCALE__ causing a build failure with some
packages (such as libcpprestsdk).
Therefore, this patch also changes how the Synospys ARC external
toolchain is exposed in Buildroot: it no longer advertise locale
support.
Fixes:
http://autobuild.buildroot.org/results/e6778e60cc1ea455f5b4511d5824f04d8040f67b
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Previously, gen-bootlin-toolchains did not add a `depends` guard to
limit the available toolchains based on the minimum required GCC version
for the user selected CPU tuning.
Now, the proper BR2_ARCH_NEEDS_GCC_AT_LEAST_X guard will be added based
on the version of GCC provided by the toolchain.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
[yann.morin.1998@free.fr: regenerate the toolchain list]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Previously, it was possible to select an external toolchain that did not
support the GCC arch tuning the user had selected. This is problematic
because it can lead to confusing error messages during builds [0].
Now, external toolchain selections will be filtered to only those that
support the required GCC version specified by the target arch tuning.
Note: this patch does not touch the Bootlin toolchain config file as it
is generated by a script.
Additional note: there is "soft" support for toolchains prior to GCC 4.8
but there are no accompanying BR2_ARCH_NEEDS_GCC_AT_LEAST_X symbols.
Instead of adding those, just use BR2_ARCH_NEEDS_GCC_AT_LEAST_4_8 which
is the minimum GCC version with claimed support [1].
[0]: https://lists.buildroot.org/pipermail/buildroot/2023-August/671877.html
[1]: https://buildroot.org/downloads/manual/manual.html#requirement-mandatory
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
A new version of Bootlin toolchains, 2023.08, has been recently
released. Besides the usual updates of GCC, binutils, GDB, kernel
headers, and C libraries, support for AArch64 BE with musl has been
enabled, which explains why there are two new toolchains and two new
test cases.
All test cases where successfully tested:
https://gitlab.com/tpetazzoni/buildroot/-/pipelines/957304450/builds
Note that the sparcv8 uClibc toolchains are considered obsolete. They
are still available, but at some point we'll have to drop them from the
choice.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fix the following build failure:
>>> toolchain-external-codescape-img-mips 2018.09-02 Copying gdbserver
Could not find gdbserver in external toolchain
Fixes:
- http://autobuild.buildroot.org/results/b0786965e0b249c8168df855682e54cfe95fa0cc
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fix the following build failure:
>>> toolchain-external-codescape-mti-mips 2018.09-02 Copying gdbserver
Could not find gdbserver in external toolchain
Fixes:
- http://autobuild.buildroot.org/results/ead304285a9cf32bf6b9dcc7fc30acece25ec680
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
e2fsprogs package fails to build for the SH4 architecture due to a gcc
13.2.0 bug that leads to:
during RTL pass: sh_treg_combine2
rw_bitmaps.c: In function read_bitmaps_range_start:
internal compiler error: Aborted
Let's add gcc bug to avoid to deal with architectures in packages
when a gcc bug arises. Let's instead deal directly with gcc
bug number.
It's been reported upstream:
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=111001
No need to backport as gcc 13.20 was introduced recently in
buildroot.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libheif package fails to build for the M68K architecture due to a binutils
bug that leads to:
Internal error in emit_expr_encoded at dw2gencfi.c:215
Let's add binutils bug to avoid to deal with architectures in packages
when a binutils bug arises. Let's instead deal directly with binutils
bug number.
It's been reported upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=30730
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch allows to use an external toolchain based on gcc 13.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In order to add gcc 13 support for internal and external toolchain in
follow-up commits, introduce BR2_TOOLCHAIN_GCC_AT_LEAST_13 symbol.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
check_fortran will display an error message if there is no Fortran
compiler in the toolchain. In the past, running into this error message
would be unlikely, since the Fortran test was only execuded when
BR2_TOOLCHAIN_HAS_FORTRAN was set.
However, since commit c7f641cbaa (toolchain/toolchain-external: always
call checks with dependencies), the Fortran check is unconditional. The
error itself benign, and the macro will handle the situation correctly,
since that is what it is designed to do. However, the error message
looks ugly and can be confusing.
[...]
>>> toolchain-external-custom Extracting
>>> toolchain-external-custom Patching
>>> toolchain-external-custom Configuring
/bin/bash: line 1: .../bin/aarch64-linux-gfortran: No such file or directory
>>> toolchain-external-custom Building
... everything continues normally ...
Let's suppress the error message, since triggerig the error is an
integral part of how the test works and doesn't mean that anything is
wrong.
Signed-off-by: Markus Mayer <mmayer@broadcom.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Call these unconditionally to make sure proper support is flagged so
proper dependencies are included in the resultant filesystem.
Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
