In order to add gcc 9 support for internal and external toolchain in
follow-up commits, introduce BR2_TOOLCHAIN_GCC_AT_LEAST_9 symbol.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
gcc bug 90620 appears with gcc 8.x so remove the version check
dependency and keep only the BR2_microblaze one.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
dmalloc and fxload fail to build for the Microblaze architecture with
optimization enabled with gcc < 8.x, with the following failure:
Error: PC relative branch to label logerror which is not in the instruction space
Error: operation combines symbols in different segments
The following defconfig allows to reproduce the issue:
BR2_microblazeel=y
BR2_OPTIMIZE_2=y
BR2_KERNEL_HEADERS_5_0=y
BR2_GCC_VERSION_7_X=y
BR2_PACKAGE_FXLOAD=y
The gcc bug was reported at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63261 and is fixed as of
gcc 8.x.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
GCC fails building the haproxy package for the Microblaze architecture:
http://autobuild.buildroot.org/results/64706f96db793777de9d3ec63b0a47d776cf33fd/
The gcc bug was originally reported gpsd:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90620
This gcc bug no longer appeared with gcc 8.x but reappeared in gcc
9.x, so we introduce a config symbol so that packages can work it
around by disabling optimization.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Gcc bug 85180 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180) has
been fixed on Gcc version >= 8.x, so this commit adjusts the
BR2_TOOLCHAIN_HAS_GCC_BUG_85180 option to no longer be true when the
gcc version is >= 8.x.
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Reviewed-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Add new BR2_TOOLCHAIN_HAS_OPENMP option for toolchains with OpenMP
support.
Signed-off-by: Ed Blake <ed.blake@sondrel.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
GCC uses thunk functions to adjust the 'this' pointer when calling C++
member functions in classes derived with multiple inheritance.
Generation of thunk functions requires support from the compiler back
end. In the absence of that support target-independent code in the C++
front end is used to generate thunk functions, but it does not support
vararg functions.
Support for this feature is currently missing in or1k and xtensa
toolchains.
Add hidden option BR2_TOOLCHAIN_SUPPORTS_VARIADIC_MI_THUNK that
indicates presence of this feature in the toolchain. Add dependency to
packages that require this feature to be built.
Fixes:
http://autobuild.buildroot.net/results/c9e660c764edbd7cf0ae54ab0f0f412464721446/http://autobuild.buildroot.net/results/9a3bf4b411c418ea78d59e35d23ba865dd453890/
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
It is set when the platform exposes the struct ucontext_t.
This avoids duplication of logic inside each package requiring
the use of that type.
Signed-off-by: Patrick Havelange <patrick.havelange@essensium.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add BR2_TOOLCHAIN_SUPPORTS_ALWAYS_LOCKFREE_ATOMIC_INTS variable and
use it in BR2_TOOLCHAIN_HAS_GCC_BUG_64735.
This new variable will be used to select boost atomic when lock-free
atomic ints are not available
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
In order to add gcc 8 support for internal and external toolchain in
follow-up commits, introduce BR2_TOOLCHAIN_GCC_AT_LEAST_8 symbol.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Commit b9882925a4 (toolchain: introduce
BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS) added this symbol to identify
Blackfin toolchains without shadow passwords support. We no longer
support Blackfin.
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
... to follow the convention: type, default, depends on, select, help.
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
toolchain-common.in is a Config.in file with an uncommon name.
It is just included by toolchain/Config.in, and toolchain/Config.in is
not that long, so instead of renaming the file, merge it to
toolchain/Config.in.
Move the raw contents from the file to the exact location it is
currently included in order to not change the order in the menu.
Update the references in the manual as well.
Suggested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Ricardo Martincoski <ricardo.martincoski@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Some cores are not supported by upstream gcc.
Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some cores are not supported by upstream gcc.
Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Upstream gcc does not have support for C-Sky, and we do not have a
vendor tree for it either (yet?).
Use the newly-introduced symbol to state so, rather than have the
exclusion in the toolchain choice.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some architectures or specific cores do not have support in upstream
gcc. Currently, they are individually listed as exclusions in the
toolchain choice.
This poses a maintainance burden, as the knowledge about what gcc
version supports what architecture is split across many places: the
toolchain choice, the gcc version choice, the external toolchains.
As a first step, add a blind option that architectures or individual
cores may select to indicate they lack support in our internal backend.
Actual use of the option will come in followup patches.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Commit 1b974425 (MIPS: add support for M6201 cores) explained that the
new core was not supported by upstream gcc, and as of gcc-8-trunk
that's still the case.
Ditto for 3cfbeb83 (MIPS: add support for P6600 cores).
This means that we currently allow to build an internal tolchain for
those cores, yet we have no suitable gcc version.
Disable the internal backend in this case.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This new boolean is true if the toolchain provides a built-in
full-featured implementation of gettext (glibc), and false if only a
stub implementation is provided (uclibc, musl).
This will be used in follow-up commits to decide whether libintl needs
to be built by gettext or not.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This commit provides basic support for the C-SKY architecture.
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
[Thomas: minor tweaks.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The default Blackfin processor in Buildroot isn't supported by
gcc 6.1.0, so use bf532 as default. Disable any bf6xx processors
for internal toolchain users.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As described at:
4520524ba0
this commit continues a series of updates of ARC tools.
This time we're updating tools to arc-2016.09-eng007 tag plus a
couple of fixes on top of it that will all make its way in the
next engineering build.
We hope this patch will cure most buildroot ARC failures as it
contains important fixes:
1) PIE fix. We have added PIE support to ARC toolchain at last.
So that should prevent breakage of many packages. As ARC now
supports PIE we remove ARC from BR2_TOOLCHAIN_SUPPORTS_PIE
exclusion in toolchain/Config.in file.
2) Assembler fix. This patch also have changes that fixes frequent
assembler failures, e.g.:
http://autobuild.buildroot.net/results/543/5430b902d900943a34c1888e7e410bd5df367bc2//
We still keep GDB as it is of arc-2016.03 release because there're some
issues we'd like to resolve before releasing it to wider audience.
So again note this is next engineering builds of arc-2016.09 series
and it might have all kinds of breakages, please don't use it for
production builds.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
[Thomas: remove uClibc PIE patch, since we have bumped uClibc in the
mean time, to a version that contains the PIE fix for ARC.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
uClibc-ng does not support PIE for some architectures as
arc and m68k. It isn't implemented in the static linking case, too.
With musl toolchains you might have static PIE support with little
patching of gcc. Static linking for GNU libc isn't enabled in
buildroot. Fixup any package using special treatment of PIE.
(grep -ir pie package/*/*.mk)
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
[Thomas: use positive logic.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With gcc 6.1.0 and binutils 2.26 internal bfin toolchain can be used. A
gcc patch is required, which was reported upstream.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Don't enable SSP support on external toolchains just because they use
glibc or musl. Instead of that, make the external toolchains explictily
declare if they support SSP or not. And also add a check to detect SSP
support when using custom external toolchains.
For internal toolchains we always enable SSP support for glibc and musl.
Fixes:
http://autobuild.buildroot.net/results/ac7c9b3ad2e52abfe6b79a80045e4218eeb87175/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
[Thomas:
- remove uClibc-specific SSP check, since there is now a generic
check being done.
- send potential compilation errors caused by the SSP check to
oblivion, in order to avoid causing confusion for the user.
- add autobuilder reference.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Make sure BR2_TOOLCHAIN_USES_MUSL selects BR2_TOOLCHAIN_HAS_SSP since
musl always provides SSP support (like glibc).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Remove BR2_INET_IPV6 select for predefined external toolchains.
Remove the (non)IPv6 option prompt since it's now mandatory.
And force the toolchain check now that internal uclibc is always built
with IPv6 support and external non-IPv6 toolchains are disallowed.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
There's no need for toolchains or the user to declare largefile support
since it's now mandatory.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The internal toolchain was a "best effort" approach - we strived to make
it build properly and all but it's mostly untested.
Since it's got issues disable it until it's properly fixed and tested
and leave the official ADI toolchain instead.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For now we can only support glibc.
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Enable the internal toolchain backend for aarch64.
Tested with arm_foundationv8_defconfig and ARMs foundation v8 emulator.
Both glibc & eglibc work.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The usual way to enable a package using the package infrastructure is to
use a config option so instead to add the toolchain package to the
TARGETS variable in the Makefile add a config option like all the other
toolchain packages.
[Thomas: remove comment that no longer made sense in the main
Makefile, and add a comment above the new hidden Config.in option to
explain what it is useful for.]
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
As our architecture support expands to a number of architectures that
do not implement NPTL threading, and the number of packages that
depend on NPTL specific features, it has become necessary to be able
to know whether the toolchain has NPTL support or not.
This commit adds a new BR2_TOOLCHAIN_HAS_THREADS_NPTL hidden Config.in
option that allows packages to know whether NPTL is available or not.
This hidden option is:
* Automatically enabled when glibc/eglibc or musl toolchains are
used, either internal or external.
* Automatically enabled when an internal uClibc toolchain with NPTL
support is configured. It is left disabled otherwise for internal
uClibc toolchains.
* Configured according to a visible Config.in option for custom
external uClibc toolchains.
[Peter: factor _EXTERNAL_HAS_THREADS in single if as suggested by Arnout]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
