aboutsummaryrefslogtreecommitdiff
path: root/toolchain
Commit message (Collapse)AuthorAgeFilesLines
* toolchain/toolchain-buildroot: allow ARC big endian glibc buildsGravatar Vineet Gupta2019-12-061-1/+1
| | | | | | | | The current ARC glibc version in buildroot arc-2019.09-rc1 allows to build an ARC big endian configuration, so let's allow this. Signed-off-by: Vineet Gupta <vgupta@synopsys.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* {linux, linux-headers}: add version 5.4Gravatar Marcus Folkesson2019-12-022-0/+9
| | | | | Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* package/musl: add an upstream URL to Config.inGravatar Mark Corbin2019-11-291-0/+2
| | | | | | | | | | Add an upstream URL to the help text in Config.in. This addresses the 'Missing' URL status in the package stats web page output. [Peter: also add URL to BR2_TOOLCHAIN_BUILDROOT_MUSL help] Signed-off-by: Mark Corbin <mark@dibsco.co.uk> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain/helpers: make sure we bail out when kernel headers check failsGravatar Thomas Petazzoni2019-11-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | In commit 6136765b23abd9faba610dd54ed276a777811575 ("toolchain: generate check-headers program under $(BUILD_DIR)"), the check_kernel_headers_version function was simplified to not check the return value of the check-kernel-headers.sh script, assuming that "make" does bail out on the first failing command. However, check_kernel_headers_version when used in $(2)_CONFIGURE_CMDS from pkg-toolchain-external.mk, is called in a sequence of commands, where the return value of each command is not checked. Therefore, a failure of check-kernel-headers.sh no longer aborts the build. Since all other macros are using this principle of calling "exit 1", we revert back to the same for check_kernel_headers_version, as it was done prior to 6136765b23abd9faba610dd54ed276a777811575. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Carlos Santos <unixmania@gmail.com> Reviewed-by: Carlos Santos <unixmania@gmail.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
* toolchain/toolchain-external: add a check for D language supportGravatar Eric Le Bihan2019-11-042-1/+23
| | | | | Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: expose BR2_TOOLCHAIN_EXTRA_EXTERNAL_LIBS for all toolchain typesGravatar Matt Weber2019-10-283-9/+15
| | | | | | | | | | | | | | | | | | This patch extends the "copy extra GCC libraries to target" feature to also work for internal toolchains. The variable has been renamed to be BR2_TOOLCHAIN_EXTRA_LIBS and the configuration option moved under the generic toolchain package. For external toolchains, the step that does the copy is still in the copy_toolchain_lib_root() helper which copies from the sysroot to the target. For the internal toolchain, the host gcc-final package does a post install hook to copy the libraries from the toolchain build folders to both the sysroot and target(!static). Examples where this can be useful is for adding debug libraries to the target like the GCC libsanitizer (libasan/liblsan/...). Cc: Markus Mayer <mmayer@broadcom.com> Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain/toolchain: set TOOLCHAIN_INSTALL_STAGING only onceGravatar Arnout Vandecappelle (Essensium/Mind)2019-10-271-1/+1
| | | | | | | | | | | | Currently, we set TOOLCHAIN_INSTALL_STAGING three times: once (conditionally) in toolchain.mk, and once each (unconditionally) in pkg-cmake.mk and pkg-meson.mk. This is a little bit messy... Set it just once, unconditionally, in toolchain.mk where it belongs. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/toolchain-external: restrict copying of dynamic loader to ld*.so.*Gravatar Thomas De Schampheleire2019-10-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 32bec8ee2fb00c6750fa842bbb0eb79b0c081fa2 ("toolchain-external: copy ld*.so* for all C libraries") changed (among other things) the glob pattern to catch the dynamic loader from ld*.so.* to ld*.so* thus now matching files like 'ld-2.20.so' in addition to files like 'ld.so.1'. However, there is no apparent reason why that change was made. It is not explicitly mentioned in the commit message as to why that would be needed, nor is clear based on the rest of the changes in that commit. But it turns out that it causes too many files to be copied with some toolchains. In most toolchains, the structure looks like this: -rwxr-xr-x 1 tdescham tdescham 834364 Feb 16 21:23 output/target/lib/ld-2.16.so lrwxrwxrwx 1 tdescham tdescham 10 Feb 16 21:23 output/target/lib/ld.so.1 -> ld-2.16.so So, a symlink 'ld.so.1' which points to another file. Applications would have 'ld.so.1' (the link) encoded as program interpreter (readelf -l <program>, see INTERP entry) The patterns like 'ld*.so*' are passed as argument to copy_toolchain_lib_root which is defined in toolchain/helpers.mk. This macro copy_toolchain_lib_root will find all files/links matching the pattern. If a match is a regular file, it is simply copied. If it is a symbolic link, the link is copied and then the logic is recursively repeated on the link destination. That destination could either again be a link or a regular file. In the first case we recurse again, in the latter we stop and continue with the next match of the pattern. The problem this patch is solving is when a toolchain does not have this structure with a link and a real file, but rather two actual files: -rwxr-xr-x 1 tdescham tdescham 170892 Feb 16 21:55 output/target/lib/ld-2.20.so -rwxr-xr-x 1 tdescham tdescham 170892 Feb 16 21:55 output/target/lib/ld.so.1 In this case the pattern 'ld*.so*' would find two regular file matches and copy both. On the other hand, the pattern 'ld*.so.*' would only find the 'ld.so.1' file and copy just that. This saves about 170K in rootfs size. Closer inspection reveals that this particular toolchain has more such dedoubled symbolic links, e.g. the standard pattern of 'usr/lib/libfoo.so -> libfoo.so.1 -> libfoo.so.1.0.2' is not present, and each of these three components are real files. In any case, it is obvious that the toolchain itself is 'broken'. That being said, because we have the logic that recursively resolves symbolic links, TOOLCHAIN_EXTERNAL_LIBS really only needs to contain the "initial" name of the library to be copied. Therefore, revert the glob pattern back to what it was. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> [Thomas: improve the commit log with the additional details from Thomas] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/toolchain-wrapper: explicitly pass --build-id=none if BR2_REPRODUCIBLEGravatar Atharva Lele2019-10-261-0/+4
| | | | | | | | | | | | | | | | | | | Build ID is added to binaries at link time. Building in different output directories causes some packages to have different Build IDs, thus resulting in non-reproducibility. Adding "-Wl,--build-id=none" fixes this issue by disabling setting of Build ID. Diffoscope output for Build ID issue: https://gitlab.com/snippets/1886180/raw After this patch, build is reproducible - i.e. diffoscope does not produce any output. Signed-off-by: Atharva Lele <itsatharva@gmail.com> Reviewed-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/toolchain-external: add support for D languageGravatar Eric Le Bihan2019-10-252-0/+11
| | | | | Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: add support for D languageGravatar Eric Le Bihan2019-10-251-0/+3
| | | | | | | | | | | | Since version 9.1, GCC provides support for the D programming language [1]. So add an option to indicate the selected toolchain supports this language. [1] https://dlang.org/ Signed-off-by: Eric Le Bihan <eric.le.bihan.dev@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/external: copy libssp.so if SSP is enabledGravatar Yann Droneaud2019-10-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | In Buildroot, the internal toolchain backend uses the SSP support from the C library, not that of gcc. Some external toolchains come with SSP suport in gcc, which is implemented in libssp.so, rather than in the C library. When a toolchain even has both, it is up to the compiler to decide whether it will link to libssp or use the support from the C library. However, in the latter case, a (incorrectly written) package may decide to explicitly link with libssp.so when it is available (even though the compiler may have decided otherwise if left by itself). This is the case for example with sox, which results in runtime failures, such as: $ sox sox: error while loading shared libraries: libssp.so.0: cannot open shared object file: No such file or directory Even if sox is wrong in doing so, the case for libssp-only toolchains is still valid, and we must copy it as we copy other libs. Signed-off-by: Yann Droneaud <ydroneaud@opteya.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* {linux, linux-headers}: bump to version 5.3.1Gravatar James Hilliard2019-09-282-0/+9
| | | | | Signed-off-by: James Hilliard <james.hilliard1@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: generate check-headers program under $(BUILD_DIR)Gravatar Carlos Santos2019-09-252-5/+5
| | | | | | | | | | | | | | | | | Some installations mount /tmp with the 'noexec' option, which prevents running the program generated there to check the kernel headers. Avoid the problem by generating the program under $(BUILD_DIR), passed as the first argument to check-kernel-headers.sh. We could globally export a TMPDIR environment variable with some path under $(BUILD_DIR) but such solution would be too intrusive, depriving the user from the freedom to set TMPDIR at his will (or needs). Fixes: https://bugs.busybox.net/show_bug.cgi?id=12241 Signed-off-by: Carlos Santos <unixmania@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/wrapper: also dump args it was called withGravatar Yann E. MORIN2019-08-181-20/+29
| | | | | | | | | Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Reviewed-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Tested-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* core: allow br2-external trees to provide pre-configured toolchainsGravatar Yann E. MORIN2019-08-041-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since we have a choice for the pre-configured pre-built toolchains, there is no possbility for a br2-external to provide its own. The only solution so far for defconfigs in br2-external trees is to use BR2_TOOLCHAIN_EXTERNAL_CUSTOM and define all the bits by itself... This is not so convemient, so offer a way for br2-external trees to provide such pre-configured toolchains. To allow for this, we now scan each br2-external tree and look for a specific file, provides.toolchains.in. We generate a kconfig file that sources each such file, and that generated file is sourced from within the toolchain choice, thus making the toolchains from a br2-external tree possible and available in the same location as the ones known to Buildroot: Toolchain ---> Toolchain type (External toolchain) ---> Toolchain ---> (X) Arm ARM 2019.03 ( ) Linaro ARM 2018.05 ( ) Custom toolchain *** Toolchains from my-br2-ext-tree: *** ( ) My custom ARM toolchain *** Toolchains from another-br2-ext-tree: *** ( ) Another custom ARM toolchain ( ) A third custom ARM toolchain Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Vadim Kochan <vadim4j@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: allow PIC/PIE without RELROGravatar Yann E. MORIN2019-08-032-1/+5
| | | | | | | | | | | | | | | | | | | | | In commit 7484c1c3b806 (toolchain/toolchain-wrapper: add BR2_RELRO_), we added the PIC/PIE flags, but based on the RELRO_FULL condition. It is however totally possible to do a PIC/PIE executable without RELRO_FULL, as it is also valid to do a PIC/PIE build with RELRO_PARTIAL. Add a new option that now governs the PIC/PIE flags. Note: it is unknown if RELRO_FULL really needs PIC/PIE or not, so we keep the current situation, where RELRO-FULL forces PIC/PIE compilation. Decoupling can come later from an interested party. Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain: check the SSP option is knownGravatar Yann E. MORIN2019-08-032-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some toolchain vendors may have backported those options to older gcc versions, and we have no way to know, so we have to check that the user's selection is acceptable. Extend the macro that currently checks for SSP in the toolchain, with a new test that the actual SSP option is recognised and accepted. Note that the SSP option is either totaly empty, or an already-quoted string, so we can safely and easily assign it to a shell variable to test and use it. Note that we do not introduce BR2_TOOLCHAIN_HAS_SSP_STRONG, because: - our internal toolchain infra only supports gcc >= 4.9, so it has SSP strong; - of the external pre-built toolchains, only the codesourcery-arm one has a gcc-4.8 which lacks SSP strong, all the others have a gcc >= 4.9; - we'd still have to do the actual check for custom external toolchains anyway. So, we're not adding BR2_TOOLCHAIN_HAS_SSP_STRONG just for a single case. Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain/toolchain-external/toolchain-external-custom: be more flexible on ↵Gravatar Thomas Petazzoni2019-08-031-20/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gcc version The custom external toolchain logic asks the user to specify which gcc version is provided by the toolchain. The list of gcc versions given by Buildroot is restricted depending on the selected CPU architecture using the BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz config options. However, these config options generally indicate in which upstream gcc version the support for the selected architecture was introduced. But in practice, it is possible that an external toolchain uses some non-upstream gcc code, providing support for a CPU architecture before it was merged in upstream gcc. A specific example is that there are pre-built external toolchains for the C-SKY CPU architecture that are based on gcc 6.x, even if the support for it was only added in upstream gcc 9.x. Due to the BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz options, only gcc >= 9.x can be selected for C-SKY, preventing the use of such a custom toolchain. In addition, those dependencies are in fact not really needed: Buildroot will check that the gcc version provided matches what the user declared in the configuration. And if the gcc provided by the toolchain does support that CPU architecture, then well, so be it, there's no need to restrict the gcc version selected. So we simply get rid of these dependencies on BR2_ARCH_NEEDS_GCC_AT_LEAST_xyz, and also don't use them anymore to chose a default value for the gcc version. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Acked-by: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: fix find_sysrootGravatar Yann E. MORIN2019-08-011-1/+1
| | | | | | | | | | | | | | | | | | | | Commit 23c0e97b29a (toolchain-external: anchor sysroot regex with /) tried to make the find-sysroot work more consistently, especially for toolchains where the C library is located in a sub-directory, like the "Realtek mips toolchain". After that patch, the '/' that was trailing in the returned path got removed now. This in turn breaks the Codesourcery toolchain. We fix that by appending the now-missing trailing '/'. Fixes: http://autobuild.buildroot.net/results/9284d571668148febce23d96a9c0a97a6b2b43dc Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: 陈小 刚 <shawn_chen@realsil.com.cn> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain-external: anchor sysroot regex with /Gravatar 陈小 刚2019-08-011-1/+1
| | | | | | | | | Anchor the regex in toolchain_find_sysroot macro with a / to avoid unexpected substitution for Realtek mips toolchain, for which the libc.a path ends with 'mips-linux-uclibc/lib/libc.a'. Signed-off-by: 陈小 刚 <shawn_chen@realsil.com.cn> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain-buildroot: musl only supports 64bit variant of risc-vGravatar Peter Korsgaard2019-07-301-1/+1
| | | | | Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: enable musl for riscvGravatar Jörg Krause2019-07-301-1/+1
| | | | | | | | Since version 1.1.23 musl supports the RISC-V architecture. Signed-off-by: Jörg Krause <joerg.krause@embedded.rocks> Tested-by: Mark Corbin <mark.corbin@embecosm.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: allow architectures to enforce compilation flagsGravatar Yann E. MORIN2019-07-181-0/+1
| | | | | | | | | Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Arnout Vandecappelle <arnout@mind.be> Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* {linux, linux-headers}: bump to version 5.2Gravatar Serhii Sakhno2019-07-142-0/+9
| | | | | | Signed-off-by: Serhii Sakhno <sergei.sakhno@gmail.com> [Peter: default to 5.2.x kernel headers] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: add gcc 9 entryGravatar Romain Naour2019-06-221-0/+6
| | | | | | | | This patch allows to use an external toolchain based on gcc 9. 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>
* toolchain: add gcc 9 entryGravatar Romain Naour2019-06-221-0/+5
| | | | | | | | | 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>
* toolchain: gcc bug 90620 has not been fixed in gcc 8.xGravatar Giulio Benetti2019-06-221-2/+1
| | | | | | | | 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>
* toolchain: introduce BR2_TOOLCHAIN_HAS_GCC_BUG_63261Gravatar Giulio Benetti2019-06-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: introduce BR2_TOOLCHAIN_HAS_GCC_BUG_90620Gravatar Giulio Benetti2019-06-201-0/+8
| | | | | | | | | | | | | | | | 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>
* toolchain-external: update Arm AArch64-BE toolchain 8.3-2019.03Gravatar Romain Naour2019-06-183-8/+8
| | | | | | | | | | | | | Update to gcc 8.3, gdb 8.2, binutils 2.32. Revert to linux kernel headers 4.19 instead of 5.1-rc1 [1]. See "Release Note": https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads# [1] https://bugs.linaro.org/show_bug.cgi?id=4297 Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain-external: update Arm AArch64 toolchain 8.3-2019.03Gravatar Romain Naour2019-06-183-8/+8
| | | | | | | | | | | | | | | Update to gcc 8.3, gdb 8.2, binutils 2.32. Revert to linux kernel headers 4.19 instead of 5.1-rc1 [1]. See "Release Note": https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads# Tested with qemu_aarch64_virt_defconfig. [1] https://bugs.linaro.org/show_bug.cgi?id=4297 Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain-external: update Arm ARM toolchain 8.3-2019.03Gravatar Romain Naour2019-06-183-10/+10
| | | | | | | | | | | | | | | Update to gcc 8.3, gdb 8.2, binutils 2.32. Revert to linux kernel headers 4.19 instead of 5.1-rc1 [1]. See "Release Note": https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads# Tested with qemu_arm_vexpress_defconfig. [1] https://bugs.linaro.org/show_bug.cgi?id=4297 Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* Merge branch 'next'Gravatar Peter Korsgaard2019-06-021-1/+1
|\ | | | | | | Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
| * package/glibc: add C-SKY specific versionGravatar Guo Ren2019-05-311-1/+1
| | | | | | | | | | Signed-off-by: Guo Ren <ren_guo@c-sky.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* | toolchain/toolchain-external/toolchain-external-andes-nds32: add missing ↵Gravatar Thomas Petazzoni2019-05-311-0/+2
| | | | | | | | | | | | | | | | | | | | dependencies/select This external toolchain is pre-built for x86, so it can only work on x86 and x86-64, and for the latter, the ia32 libraries are necessary. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* | toolchain: introduce BR2_TOOLCHAIN_HAS_GCC_BUG_68485Gravatar Giulio Benetti2019-05-281-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | GCC hangs while building brotli for the Microblaze Arch: http://autobuild.buildroot.net/results/d86/d86251974a0a348a64d9a1d1fd7d02dd4aff0792/ Originally reported for gpsd: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 Still not fixed. Every Microblaze Gcc version up to and including 9.1 is affected. Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* | toolchain: gcc bug 85180 is fixed in gcc >= 8.xGravatar Giulio Benetti2019-05-221-0/+1
|/ | | | | | | | | | | 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>
* toolchain/toolchain-external-andes-nds32: disable static buildGravatar Baruch Siach2019-05-071-0/+1
| | | | | | | | | | | | | | | Buildroot does not support static build with glibc. Since this external toolchain uses glibc, disable static build with this toolchain. Fixes: http://autobuild.buildroot.net/results/3c93cfac81f15f4c18eb7ad578ad86bb7bcf1c12/ http://autobuild.buildroot.net/results/63994f51a2b224b66acfafe5b236249d867a507d/ http://autobuild.buildroot.net/results/96c3be922a96c50fbd8e68059f9ced8a2a75f9ab/ Cc: Nylon Chen <nylon7@andestech.com> Suggested-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain/toolchain-external-andes-nds32: new packageGravatar Nylon Chen2019-04-175-0/+39
| | | | | | | | | | | | | | | | | | | | | This commit adds a new package for the Andes external toolchain for the nds32 Little Endian architecture. https://github.com/vincentzwc/prebuilt-nds32-toolchain/releases/download/20180521/nds32le-linux-glibc-v3-upstream.tar.gz Signed-off-by: Che-Wei Chuang <cnoize@andestech.com> Signed-off-by: Greentime Hu <greentime@andestech.com> Signed-off-by: Nylon Chen <nylon7@andestech.com> [Thomas: - rename .mk and .hash files to carry the proper package name - fix <pkg>_SITE variable, which was incorrect - add prompt in Config.in - add missing include of Config.in in toolchain/toolchain-external/Config.in - add missing selects for RPC and SSP, since the toolchain supports both - drop BR2_TOOLCHAIN_EXTERNAL_URL option, the toolchain URL is provided by the .mk file] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain/toolchain-external-custom: support Linux 5.1Gravatar Clément Leger2019-04-071-0/+4
| | | | | Signed-off-by: Clement Leger <clement.leger@kalray.eu> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: add BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_1Gravatar Clément Leger2019-04-071-0/+5
| | | | | Signed-off-by: Clement Leger <clement.leger@kalray.eu> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: add a check for OpenMP supportGravatar Ed Blake2019-03-282-0/+21
| | | | | Signed-off-by: Ed Blake <ed.blake@sondrel.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain-external: introduce BR2_TOOLCHAIN_EXTERNAL_OPENMPGravatar Ed Blake2019-03-281-0/+8
| | | | | | | | Add a new option for custom external toolchains to enable OpenMP support. Signed-off-by: Ed Blake <ed.blake@sondrel.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain-external: enable OpenMP for supported toolchainsGravatar Ed Blake2019-03-2611-0/+11
| | | | | | | | | | | | | | | | | | | Enable OpenMP support in the following external toolchains: toolchain-external-arm-aarch64-be toolchain-external-arm-aarch64 toolchain-external-arm-arm toolchain-external-codescape-img-mips toolchain-external-codescape-mti-mips toolchain-external-codesourcery-amd64 toolchain-external-codesourcery-mips toolchain-external-linaro-aarch64-be toolchain-external-linaro-aarch64 toolchain-external-linaro-arm toolchain-external-linaro-armeb Signed-off-by: Ed Blake <ed.blake@sondrel.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain-external: introduce BR2_TOOLCHAIN_HAS_OPENMPGravatar Ed Blake2019-03-262-0/+7
| | | | | | | | 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>
* toolchain/toolchain-external-custom: support Linux 5.0 kernel headersGravatar Joel Stanley2019-03-261-0/+4
| | | | | Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: add BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_0Gravatar Joel Stanley2019-03-261-0/+5
| | | | | Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
* toolchain: set the ssp gcc option in kconfigGravatar Yann E. MORIN2019-03-132-17/+1
| | | | | | | | | | | | | | | | | | | | | Currently, we repeat all the SSP level selection deep down to the toolchain wrapper itself, where we eventually translate it to the actual SSP option to use. This is a bit redundant. Additionally, we will want to check that the toolchain actually supports that option (for those toolchain where it was backported). So, move the translation into kconfig, and add the qstrip'ed value to the additional flags passed to the wrapper. Add it before user-supplied opitons, to keep the previous behaviour (and allow anyone crazy-enough to override it with BR2_TARGET_OPTIMIZATION). Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com> Cc: Matt Weber <matthew.weber@rockwellcollins.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Reviewed-by: Matthew Weber <matthew.weber@rockwellcollins.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain: prepare to pass more additional CFLAGS via the wrapperGravatar Yann E. MORIN2019-03-131-3/+5
| | | | | | | | | | | | | | | Currently, we pass the user-supplied so-called target optimisation flags to the wrapper. We're going to have additional such CFLAGS to pass, so push-back the formatting loop to quote the options at the last moment. Reported-by: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: "Yann E. MORIN" <yann.morin@orange.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>