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>
