>From [1]:
* All GCC 8.2 features. For details on GCC 8 release series.
* Linaro specific pre-processor macros to ensure that this is a
continuation from the Linaro releases.
* Spectre v1 mitigation backport from upstream FSF trunk include the
revisions. This is an initial backport of those mitigations in
the GNU toolchain and should be regarded as support for prototyping
and early access only. Moreover, while the backports include support
for the other architectures, they are included for completeness and
all issues regarding these patches must be taken up upstream in the
https://gcc.gnu.org/bugzilla by reproducing the same with upstream
FSF trunk.
Arm is interested in feedback regarding these workarounds for
Spectre v1.
A description of the mitigation has been published on LWN.net.
See "Release Note":
[1] 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: Peter Korsgaard <peter@korsgaard.com>
>From [1]:
* All GCC 8.2 features. For details on GCC 8 release series.
* Linaro specific pre-processor macros to ensure that this is a
continuation from the Linaro releases.
* Spectre v1 mitigation backport from upstream FSF trunk include the
revisions. This is an initial backport of those mitigations in
the GNU toolchain and should be regarded as support for prototyping
and early access only. Moreover, while the backports include support
for the other architectures, they are included for completeness and
all issues regarding these patches must be taken up upstream in the
https://gcc.gnu.org/bugzilla by reproducing the same with upstream
FSF trunk.
Arm is interested in feedback regarding these workarounds for
Spectre v1.
A description of the mitigation has been published on LWN.net.
See "Release Note":
[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads#
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
>From [1]:
* All GCC 8.2 features. For details on GCC 8 release series.
* Linaro specific pre-processor macros to ensure that this is a
continuation from the Linaro releases.
* Spectre v1 mitigation backport from upstream FSF trunk include the
revisions. This is an initial backport of those mitigations in
the GNU toolchain and should be regarded as support for prototyping
and early access only. Moreover, while the backports include support
for the other architectures, they are included for completeness and
all issues regarding these patches must be taken up upstream in the
https://gcc.gnu.org/bugzilla by reproducing the same with upstream
FSF trunk.
Arm is interested in feedback regarding these workarounds for
Spectre v1.
A description of the mitigation has been published on LWN.net.
See "Release Note":
[1] 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: Peter Korsgaard <peter@korsgaard.com>
The 2016.05-06 toolchain we've had support for is pretty outdated at
this point, so update to the latest 2018.09-02 version.
Of note besides the typical component version bumps:
- The toolchains are now provided by MIPS Tech LLC after its departure
from Imagination Technologies.
- The download site changed as a result of that.
- The toolchains are now built targeting CentOS 6 rather than CentOS 5.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The 2016.05-06 toolchain we've had support for is pretty outdated at
this point, so update to the latest 2018.09-02 version.
Of note besides the typical component version bumps:
- The toolchains are now provided by MIPS Tech LLC after its departure
from Imagination Technologies.
- The download site changed as a result of that.
- The toolchains are now built targeting CentOS 6 rather than CentOS 5.
Signed-off-by: Paul Burton <paul.burton@mips.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Lets update prebuilt ARC toolchain to the most recent arc-2018.09.
Signed-off-by: Evgeniy Didin <Evgeniy.Didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
If a custom external toolchain is used, we can't enable the fortran
support. Add a new option for that.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is the same toolchain that was previously distributed by Linaro. [1]
Switch default toolchain as this toolchain supersed the Linaro AArch64-BE toolchain.
Only x86_64 host are supported, so keep Linaro toolchain for x86 host.
[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is the same toolchain that was previously distributed by Linaro. [1]
Switch default toolchain as this toolchain supersed the Linaro AArch64 toolchain.
Only x86_64 host are supported, so keep Linaro toolchain for x86 host.
Tested with qemu_aarch64_virt_defconfig.
[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This is the same toolchain that was previously distributed by Linaro. [1]
Switch default toolchain as this toolchain supersed the Linaro ARM toolchain.
Only x86_64 host are supported, so keep Linaro toolchain for x86 host.
Tested with qemu_arm_vexpress_defconfig.
[1] https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
commit e0d14fb21b (toolchain-external: drop no longer needed
CC_TARGET_<foo>_ variables) dropped the CC_TARGET_* variables, but missed
one. Fix that.
Reported-by: Mark Corbin <mark.corbin@embecosm.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since the introduction of the GCC_TARGET_<foo> variables in
arch/arch.mk in commit bd0640a213
("arch: allow GCC target options to be optionally overwritten") and
the removal of the BR2_GCC_TARGET_CPU_REVISION, the CC_TARGET_<foo>_
variables in pkg-toolchain-external.mk map 1:1 with the corresponding
GCC_TARGET_<foo> variables.
So let's drop the CC_TARGET_<foo>_ variables, and use directly the
GCC_TARGET_<foo> ones.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In commit 325bb37942, support for the
Blackfin architecture was removed. This was our only use of
BR2_GCC_TARGET_CPU_REVISION, and since this config option somewhat
complicates the calculation of the --with-cpu/-mcpu option values,
let's drop it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The BR2_GCC_TARGET_* configuration variables are copied to
corresponding GCC_TARGET_* variables which may then be optionally
modified or overwritten by architecture specific makefiles.
All makefiles must use the new GCC_TARGET_* variables instead
of the BR2_GCC_TARGET_* versions.
Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
[Thomas: simplify include of arch/arch.mk]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The check_musl function currently builds a program and verifies if the
program interpreter starts with /lib/ld-musl. While this works fine
for dynamically linked programs, this obviously doesn't work for a
purely static musl toolchain such as [1].
There is no easy way to identify a toolchain as using the musl C
library. For glibc, dynamic linking is always supported, so we look at
the dynamic linker name. For uClibc, there is a distinctive
uClibc_config.h header file. There is no such distinctive feature in
musl.
We end up resorting to looking for the string MUSL_LOCPATH, which is
used by musl locale_map.c source file. This string has been present in
musl since 2014. It certainly isn't a very stable or convincing
solution to identify the C library as being musl, but it's the best we
could find.
Note that we are sure there is a libc.a file, because the
check_unusable_toolchain function checks that there is a such a file.
[1] http://autobuild.buildroot.net/toolchains/tarballs/br-arm-musl-static-2018.05.tar.bz2
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit adds a new package for the Linaro external toolchain for
the AArch64 Big Endian architecture.
https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05
Signed-off-by: Ofer Heifetz <oferh@marvell.com>
Reviewed-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Lets update prebuilt ARC toolchain to the most recent arc-2018.03.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: arc-buildroot@synopsys.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Re-add BR2_TOOLCHAIN_HAS_SSP since the toolchain support SSP.
Tested with qemu_nios2_10m50_defconfig and Qemu 2.10.1-3.fc27 release.
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch allows to use an external toolchain based on gcc 8.
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>
There are cases where a downloaded toolchain doesn't have its binaries
placed directly in a "bin" subfolder (where BuildRoot currently looks
for them).
A common example is the official Raspberry Pi Toolchain
(https://github.com/raspberrypi/tools), which has its binaries in
"arm-bcm2708/arm-linux-gnueabihf/bin".
This commit introduces BR2_TOOLCHAIN_EXTERNAL_REL_BIN_PATH that defaults
to "bin" and can be changed as needed.
Signed-off-by: Calin Crisan <ccrisan@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Thomas: rework a bit how TOOLCHAIN_EXTERNAL_REL_BIN_PATH is defined.]
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>
libatomic, like libgcc_s, is provided by gcc, so there is no reason to
copy it over only for the glibc and uclibc cases, it should also be
copied for the musl case. Without this, a program linked with
libatomic on a musl system will fail to run due to the missing
library.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
There might be subtle differences between uClibc configuration
compared to Buildroot's one.
Native RPC now is disabled because uClinc-ng has removed it.
Signed-off-by: Evgeniy Didin <didin@synopsys.com>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: arc-buildroot@synopsys.com
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The upcoming per-package SDK functionality is heavily based on the
fact that HOST_DIR, STAGING_DIR and TARGET_DIR are evaluated during
the configure/build/install steps of the packages. Therefore, any
evaluation-during-assignment using := is going to cause problems, and
need to be turned into evaluation-during-use using =.
This patch fix up one such instance in the external toolchain code.
This change is independent from the per-package SDK functionality, and
could be applied separately.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This merges the next branch accumulated during the 2017.11 release
cycle back into the master branch.
A few conflicts had to be resolved:
- In the DEVELOPERS file, because Fabrice Fontaine was added as a
developer for libupnp in master, and for libupnp18 in
next. Resolution is simple: add him for both.
- linux/Config.in, because we updated the 4.13.x release used by
default in master, while we moved to 4.14 in next. Resolution: use
4.14.
- package/libupnp/libupnp.hash: a hash for the license file was added
in master, while the package was bumped into next. Resolution: keep
the hash for the license file, and keep the hash for the newest
version of libupnp.
- package/linux-headers/Config.in.host: default version of the kernel
headers for 4.13 was bumped to the latest 4.13.x in master, but was
changed to 4.14 in next. Resolution: use 4.14.
- package/samba4/: samba was bumped to 4.6.11 in master for security
reasons, but was bumped to 4.7.3 in next. Resolution: keep 4.7.3.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
For armv8, there are different profiles: A, M and R, like there is for
armv7.
So, rename our internal symbol to mirror what we do for armv7.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Take the conditions currently specified in the gcc version choice.
Also, the conditions explained in the commit log for 78c2a9f7 were not
all properly applied, especially the a57-a53 combo needs gcc-6, but
78c2a9f7 forgot to add the condition to gcc-4.9.
gcc-4.9 was excluded for cortex-a17 and a72, but the CodeSourcery
external toolchain, which uses 4.8, was not excluded for those two
cores. Now it is.
Remove the arch condition from gcc and the external toolchains.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
