In commit fd839aeb7f ("package/glibc:
introduce and use BR2_PACKAGE_GLIBC_ARCH_SUPPORTS and
BR2_PACKAGE_GLIBC_SUPPORTS") we moved the Config.in logic about glibc
dependencies from toolchain/toolchain-buildroot/Config.in into
package/glibc/Config.in.
Unfortunately, it is not possible to move the Config.in comments that
tell the user, within the choice..endchoice for the C library why
glibc is not currently selectable, so we had to keep them in
toolchain/toolchain-buildroot/Config.in.
Turns out that the comments were out of sync with the dependencies,
and two comments were missing. This commit adds the missing ones, and
adds a comment in package/glibc/Config.in explaining that we need to
be careful about updating toolchain/toolchain-buildroot/Config.in as
well.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is no need to have configuration files direbtly set the
BR2_PACKAGE_HOST_ELF2FLT option. The need for the elf2flt utility is
automatically determined by gcc build in package/gcc/gcc.mk according to
the BR2_BINFMT_FLAT option.
Accordingly, we can remove the file package/elf2flt/Config.in.host to
get rid of the BR2_PACKAGE_HOST_ELF2FLT option. BR2_STRIP_strip
dependency on this option is replaced with a dependency on
BR2_BINFMT_ELF.
To stay consistent with the fact that elf2flt supports only the arm, sh,
sparc, xtensa and riscv-64 architectures, a dependency on these
architectures is added to the BR2_BINFMT_FLAT option in arch/Config.in.
Board configuration files setting the BR2_PACKAGE_HOST_ELF2FLT option
are also updated.
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
float128 is available on PowerPC with VSX [1] but it requires
libquadmath support.
[1] https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Cyril Bur <cyrilbur@gmail.com>
Cc: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As we're about to remove the nds32 architecture support from
Buildroot, drop the toolchain-external-andes-nds32 external toolchain
package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Yu Chien Peter Lin <peterlin@andestech.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Some external toolchains do not have gdbserver available, but the
option BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY is always visible. And
when enabled, this option aborts with an error when gdbserver cannot
be found:
Could not find gdbserver in external toolchain
Due to that, some random configurations fail to build when
BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY=y, for example with the Bootlin
toolchains for Microblaze or OpenRISC (because there's no GDB support
for those architectures).
One solution could be to make "Could not find gdbserver in external
toolchain" a warning instead of a hard error, but then nobody would
notice about this issue, in cases where it should legitimately abort
with a hard error.
So, the clean solution would be to add a
BR2_TOOLCHAIN_EXTERNAL_HAS_GDBSERVER. But that means all existing
external toolchains would have to be modified to select this option.
Instead, and as an exception, we chose to use inverted logic, and
create an option that is the opposite:
BR2_TOOLCHAIN_EXTERNAL_HAS_NO_GDBSERVER. By default, we assume
external toolchains have gdbserver. If
BR2_TOOLCHAIN_EXTERNAL_HAS_NO_GDBSERVER is enabled, we disallow the
BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY option.
Note that the case of custom external toolchain does not matter: by
definition they are not tested by the autobuilders, and by definition,
we cannot know in menuconfig if the custom toolchain has or does not
have gdbserver. We could make a user-visible option for it, but that
adds no value over simply erroring out because the gdbserver binary
can't be found.
Similarly, we could add
default y if BR2_PACKAGE_GDB_ARCH_SUPPORTS
but that would make it impossible for someone to include a custom
gdbserver in their external toolchain, and gives no benefit at all.
This will help fixing:
http://autobuild.buildroot.net/results/6315ef7b66ee4ae8f870c92186bc674d65f62f2c/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This commit regenerates the toolchain-external-bootlin Config.in file
after the ARM toolchain description was modified to make sure they
only match the ARM little endian configurations.
Fixes:
http://autobuild.buildroot.net/results/7befbb686bb972016ba4e742976dcdb3fed1be11/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This commit allows to get a proper description of the dependencies for
the RISC-V 64-bit toolchain, that includes the BR2_USE_MMU dependency.
Fixes:
http://autobuild.buildroot.net/results/d6aee9b275b1ec399aea59758ac8f69fdc5691fc/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This commit is simply the result of regenerating the
toolchain-external-bootlin package after gen-bootlin-toolchains was
changed in commit "support/scripts/gen-bootlin-toolchains: properly
take into account !BR2_STATIC_LIBS for glibc toolchains".
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In this commit BR2_PACKAGE_MUSL_SUPPORTS looks redundant with
BR2_PACKAGE_MUSL_ARCH_SUPPORTS, but for other C libraries, like glibc,
it can be different.
To be consistent, we use the same pattern for musl.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
In this commit BR2_PACKAGE_UCLIBC_SUPPORTS looks redundant with
BR2_PACKAGE_UCLIBC_ARCH_SUPPORTS, but for other C libraries, like glibc,
it can be different.
To be consistent, we use the same pattern for uClibc.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
As part of this, the dependency of the comment "glibc needs a
toolchain w/ dynamic library, kernel headers >= 3.2" is changed to use
BR2_PACKAGE_GLIBC_ARCH_SUPPORTS instead of just BR2_USE_MMU, so that
the comment only appears on architectures for which glibc is supported
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
https://sourceware.org/pipermail/libc-alpha/2022-February/136040.html
- Remove upstreamed patch 0001. Patches to localedef are not upstream.
- allow to use optimization CFLAGS (not CPPFLAGS) which are nowadays
supported by upstream (except nios2)
- enable support for or1k, which is now included upstream
- runtime tested with qemu-system for aarch64/arm/microblaze/mips/mips64/nios2/
or1k/powerpc/powerpc64/powerpc64le/riscv32/riscv64/s390x/sh4/sparc64/x86/x86_64
Since only a single version is supported (no csky fork any more), move
the hash file out of the version directory. Also, make a symlink from
the localedef to the glibc hash file rather than copying it.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
Tested-by: Petr Vorel <petr.vorel@gmail.com>
[Arnout: make localedef.hash a symlink]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
The gcc toolchain is also released for an aarch64 host target and allow
that configuration to be used as part of the configuration. Tested on
on a aarch64 linux docker.
Signed-off-by: Charles Hardin <ckhardin@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This reverts commit 8e91385a2c.
This commit is incorrect, as it is perfectly valid for
BR2_TOOLCHAIN_EXTERNAL_PATH to be empty. The help text of
BR2_TOOLCHAIN_EXTERNAL_PATH even documents it as a supported case:
If empty, the compiler will be searched in $PATH.
Commit 392b0a26f5 ("toolchain-external:
default BR2_TOOLCHAIN_EXTERNAL_PATH to empty") even made that the
default saying "In addition, it in fact works correctly when it is
empty. In that case, the toolchain will be searched in PATH."
A user has reported that commit
8945ba4948 (the backport of 8e91385a2c to
the 2022.02.x LTS branch) breaks his use-case:
https://lore.kernel.org/buildroot/CADBnMvhgaozAgZgy3njckjL1i0U6bZ0fLrq-kdFF-qpGhFWgmw@mail.gmail.com/
Reported-by: Kristof Havasi <havasiefr@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: reference 8e91385a2c on master]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This patch allows to use an external toolchain based on gcc 12.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
In order to add gcc 12 support for internal and external toolchain
in follow-up commits, introduce BR2_TOOLCHAIN_GCC_AT_LEAST_12 symbol.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
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>
