This makes the condition easier to read and it's easier to maintain the
gcc bug too because we don't have to take care about new gcc versions.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
[yann.morin.1998@free.fr: fix comment while at it]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
This makes the condition easier to read and it's easier to maintain the
gcc bug too because we don't have to take care about new gcc versions.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Back many years ago, we developed an Eclipse plugin that simplified
the usage of Buildroot toolchains. Enabling the BR2_ECLIPSE_REGISTER=y
was registering the Buildroot toolchain into a special file in your
HOME folder that the Eclipse plugin would recognize to allow to
directly use the Buildroot cross-compiler.
This Eclipse plugin has not been maintained for years. The last commit
in the repository dates back from September 2017. Since then Eclipse
has moved on, and the plugin is no longer compatible with current
versions of Eclipse.
Also, Eclipse is probably no longer that widely used in the embedded
Linux space, as other more modern IDEs have become more popular.
All in all, it's time to say good bye to this Eclipse integration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Gcc bug 99410 reappeared while building with gcc 11.x and while
testing it also shows up with gcc 12.x, so let's enable this bug for
all gcc versions except gcc 8.x.
Fixes:
http://autobuild.buildroot.net/results/64e54ef5ba3a3dee391b788315615d57a1dd9fa2/
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
While introducing gcc bug 99410 I've named BR2_TOOLCHAIN_HAS_GCC_BUG_ to
99140 that is wrong. So let's fix this by changing bug option to
BR2_TOOLCHAIN_HAS_GCC_BUG_99410.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The MMU option is currently located in the "Toolchain" menu, but it
doesn't make sense as it's really architecture related. In addition,
the selection of MMU has an impact on the choice of binary format
available, which is visible in the architecture menu.
Therefore, this commit moves the MMU option into the architecture
menu.
However, if we simply move it in arch/Config.in, it means that we
would have the following order of options:
Target architecture
Target architecture variant
ABI
MMU
Binary format
But really, the MMU option should be right below the Target
architecture variant, and the available ABIs derived from that.
The variant and ABI are arch-specfic, and defined in the per-arch
Config.in fragments; a Kconfig option can have only one prompt defined,
even under conditions, and appears at the place in the menu where its
prompt was defined. So, there is no (easy) possibility to have a
generic option appear where we want it.
Since in fact only 2 architectures show a visible prompt for the MMU
option (RISC-V and Xtensa), we move this option in
arch/Config.in.riscv and arch/Config.in.xtensa.
Some walkthrough the commit:
- BR2_ARCH_HAS_MMU_MANDATORY and BR2_ARCH_HAS_MMU_OPTIONAL are
removed as they are no longer needed
- BR2_USE_MMU becomes a hidden boolean
- All the places where we used to select BR2_ARCH_HAS_MMU_MANDATORY
now select BR2_USE_MMU directly.
- Introduce BR2_RISCV_USE_MMU and BR2_XTENSA_USE_MMU.
- All defconfigs that used "# BR2_USE_MMU is not set" are switched to
using the new option.
All in all, this simplifies things quite a bit, and allows to have a
good option ordering in the Target architecture menu.
This commit might raise a concern in terms of backward compatibility
with existing configurations. The only configurations that will be
broken by this change are RISC-V noMMU (which was very recently
introduced) and Xtensa noMMU (which we can probably agree is not such
a widely popular configuration).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Tested-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
[yann.morin.1998@free.fr:
- expand further why we need per-arch MMU options
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
