summaryrefslogtreecommitdiffstats
path: root/package/gcc
Commit message (Collapse)AuthorAgeFilesLines
* gcc: bump 5.x series to version 5.4.0Gustavo Zacarias2016-06-0730-156/+3
| | | | | | | 130-fix_build_with_gcc-6.patch is upstream so remove it. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* uclibc: add microblaze supportWaldemar Brodkorb2016-06-052-0/+45
| | | | | | | | | Latest uClibc-ng 1.0.15 release fixed open issues with microblaze shared library and linuxthreads support. gcc 4.9.3 and gcc 5.3.0 require a small patch. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* Merge branch 'next'Peter Korsgaard2016-06-0116-292/+831
|\ | | | | | | Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
| * toolchain: bump ARC tools to arc-2016.03 releaseAlexey Brodkin2016-05-199-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change switches ARC tools to the most recent arc-2016.03 version. ARC GNU tools of version arc-2016.03 bring some quite significant changes like: * Binutils v2.26+ (upstream commit id 202ac19 with additional ARC * patches) * GCC v4.8.5 * GDB 7.10 More about changes, improvements and fixes could be found here: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2016.03 Note in this change we're adding sha512 checksums for both binutils and gcc tarballs fetched from GitHub. Build and run-tested in nSIM for both ARC700 and ARC HS38. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
| * package/gcc: 4.8.x to 5.x: backport a fix for building gcc with gcc-6Samuel Martin2016-05-174-0/+612
| | | | | | | | | | | | | | | | | | When the host system compiler is gcc-6, this patch is needed to build Buildroot toolchain and cleanly apply on gcc version 4.8.x to 5.x (not needed for 4.7.x series). Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
| * toolchain: remove eglibc supportThomas Petazzoni2016-05-171-1/+1
| | | | | | | | | | | | | | | | The eglibc support has been marked deprecated since 2015.08, so it's time to remove it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
| * toolchain: bump ARC tools to arc-2016.03-rc2Alexey Brodkin2016-05-1112-290/+216
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change switches ARC tools to RC2 of the most recent arc-2016.03 version. Essentially once final release is ready version will be bumped again. ARC GNU tools of version arc-2016.03 bring some quite significant changes like: * Binutils v2.26+ (upstream commit id 202ac19 with additional ARC patches) * GCC v4.8.5 * GDB 7.10 More about changes, improvements and fixes could be found here: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2016.03-rc2 Also in this change we realign custom Buildroot patches for binutils and gcc for ARC tools. Looks like earlier most of arch-independent patches for binutils and gcc were either unintentionally removed or not even added in patch folders for ARC's binutils and gcc. Now arch-independent patches for binutils-2.26 and gcc-4.8.5 were added in package/{binutils|gcc}/arc-2016.03-rc2 folders. Build and run-tested in nSIM for both ARC700 and ARC HS38. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* | gcc/libmudflap: also unavailable for gcc 6.xBernd Kuhls2016-05-311-0/+1
| | | | | | | | | | | | | | | | | | libmudflap was removed in gcc 4.9: https://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* | gcc: fix build of gcc 6.x on MicroblazeThomas Petazzoni2016-05-171-166/+0
|/ | | | | | | | | | | | | | | Due to patch 840-microblaze-enable-dwarf-eh-support.patch, gcc 6.x does not build: ../../gcc/config/microblaze/microblaze.c: In function 'void microblaze_expand_epilogue()': ../../gcc/config/microblaze/microblaze.c:3046: error: 'gen_rtx_raw_REG' was not declared in this scope This patch was originally added to gcc 4.9 to make it capable of building glibc. However, this is no longer needed with gcc 6.x, which builds glibc just fine. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: add coldfire supportWaldemar Brodkorb2016-04-305-0/+81
| | | | | | | | Add support for m68k/coldfire. A gcc patch is required to avoid gcc ICE. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: add support for gcc 6Thomas Petazzoni2016-04-279-0/+321
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds the support for gcc 6. This release allows to remove a large number of our gcc patches, mainly thanks to the Xtensa and musl related patches being merged upstream. Patches kept with no changes: 100-uclibc-conf.patch 301-missing-execinfo_h.patch 810-arm-softfloat-libgcc.patch 830-arm_unbreak_armv4t.patch 840-microblaze-enable-dwarf-eh-support.patch 860-cilk-wchar.patch 890-fix-m68k-compile.patch Patches dropped because they have been merged upstream, or were already upstream backports: 120-gcc-config.gcc-fix-typo-for-powerpc-e6500-cpu_is_64b.patch (merged) 850-libstdcxx-uclibc-c99.patch (merged in a different form, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393) 870-xtensa-add-mauto-litpools-option.patch (upstream backport) 871-xtensa-reimplement-register-spilling.patch (upstream backport) 872-xtensa-use-unwind-dw2-fde-dip-instead-of-unwind-dw2-.patch (upstream backport) 873-xtensa-fix-_Unwind_GetCFA.patch (upstream backport) 874-xtensa-add-uclinux-support.patch (upstream backport) 900-libitm-fixes-for-musl-support.patch (upstream backport) 901-fixincludes-update-for-musl-support.patch (upstream backport) 902-unwind-fix-for-musl.patch (upstream backport) 903-libstdc++-libgfortran-gthr-workaround-for-musl.patch (upstream backport) 904-musl-libc-config.patch (upstream backport) 905-add-musl-support-to-gcc.patch (upstream backport) 905-add-musl-support-to-gcc.patch (upstream backport) 906-mips-musl-support.patch (upstream backport) 907-x86-musl-support.patch (upstream backport) 908-arm-musl-support.patch (upstream backport) 909-aarch64-musl-support.patch (upstream backport) Successfully build-time and run-time tested with qemu_arm_vexpress_defconfig, using gcc 6.x, both in uClibc and musl configurations. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* gcc: disable split-stack for non-thread buildsWaldemar Brodkorb2016-04-193-0/+42
| | | | | | | | This fixes bug 8766: https://bugs.busybox.net/show_bug.cgi?id=8766 Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: fix ccache hash of patches in BR2_GLOBAL_PATCH_DIRArnout Vandecappelle (Essensium/Mind)2016-04-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | In commit f4682cf933, a hash of the patches applied to gcc was created to make sure that ccache can properly detect when the toolchain has changed. The patches applied to gcc consist of the buildroot patches in package/gcc, but also potentially patches in BR2_GLOBAL_PATCH_DIR. However, the path to the patches in BR2_GLOBAL_PATCH_DIR was corrected incorrectly, because it misses a /. So instead of: $(BR2_GLOBAL_PATCH_DIR)/gcc-initial/*.patch it would look for $(BR2_GLOBAL_PATCH_DIR)gcc-initial/*.patch In other words, if BR2_GLOBAL_PATCH_DIR doesn't end with /, the patches in BR2_GLOBAL_PATCH_DIR are not taken into account in the ccache hash. To fix, add the missing / Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: He Chunhui <hchunhui@mail.ustc.edu.cn> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: add xtensa uClinux supportMax Filippov2016-03-313-0/+522
| | | | | | Backported from: r228450 Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: fix libsanitizer build with _FILE_OFFSET_BITS=64Max Filippov2016-03-241-0/+37
| | | | | | | | | | | | | | | | | | | | After the commit f67a4f50e2ace3a2 "gcc: preserve CXXFLAGS_FOR_TARGET" target CFLAGS are passed to all libraries bundled with gcc. This breaks libsanitizer on gcc-4.9.x when building with _FILE_OFFSET_BITS=64: error: size of array ‘assertion_failed__837’ is negative ... libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:837:1: note: in expansion of macro ‘CHECK_SIZE_AND_OFFSET’ CHECK_SIZE_AND_OFFSET(dirent, d_ino); This issue is fixed in the libsanitizer mainline and in gcc-5.x. There's no issue with gcc-4.8.x and earlier. Reported-by: Julien CORJON <corjon.j@ecagroup.com> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Backported from: https://llvm.org/svn/llvm-project/compiler-rt/trunk@220328 Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Revert "package/gcc: fix libgcc build for xtensa"Max Filippov2016-03-201-7/+0
| | | | | | | | | | | | | | | | This reverts commit c44cf2cc97df1729577263d2b0cb5263e8cdc4c1. Now that xtensa gas don't move literals into .init and .fini this fix is no longer needed. See upstream commit https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4111950f363221c4641dc2f33bea61cc94f34906, which was backported to all supported binutils version, under the name *-xtensa-fix-.init-.fini-literals-moving.patch. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> [Thomas: add more details in the commit log, as suggested by Yann E. Morin, and using information provided by Max.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch/m68k: re-enable the architectureWaldemar Brodkorb2016-03-203-0/+45
| | | | | | | This allows to build a m68k toolchain with uClibc. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Revert "gcc/gcc-final: pass TARGET_ABI flags to configure with ↵Max Filippov2016-03-151-4/+0
| | | | | | | | | | | | | | --enable-cxx-flags" This reverts commit 2dcab526a97d1dbcb73c3cd578e5bf2853853a10. Now that gcc correctly propagates CXXFLAGS_FOR_TARGET for libstdc++ build this is no longer needed. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* gcc: preserve CXXFLAGS_FOR_TARGETMax Filippov2016-03-153-0/+75
| | | | | | | | | | | | | | | | | | | gcc-4.7.x, gcc-4.8.x and gcc-4.9.x don't propagate CXXFLAGS_FOR_TARGET to CXXFLAGS for libstdc++ build. As a result libstdc++ is built without TARGET_CFLAGS and may fail to link with applications using it, see e.g. http://autobuild.buildroot.net/results/81a3bca5cbcf789c7ce1aa221a6a4154dd7c3917/ Instead of passing TARGET_ABI or TARGET_CFLAGS for libstdc++ in --enable-cxx-flags parameter backport the patch that fixes propagation of CXXFLAGS_FOR_TARGET to CXXFLAGS. This issue is fixed in gcc-5.x Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* gcc: fix dynamic linker path for mips soft-floatThomas Petazzoni2016-03-103-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit updates the gcc musl patches for gcc 4.7, 4.8 and 4.9 so that the path to the dynamic linker encoded as "program interpreter" in the generated binaries actually matches the symbolic link installed by musl when building for mips soft-float. Indeed, musl installs a symlink called ld-musl-mipsel-sf.so.1, but gcc currently generates binaries that use /lib/ld-musl-mips.so as program interpreter. The fix is simply the one from https://bitbucket.org/GregorR/musl-cross/commits/825219202365, i.e adjust MUSL_DYNAMIC_LINKER in our musl gcc patches. Thanks to these patches: $ ./host/usr/bin/mipsel-linux-readelf -a ./target/bin/busybox [...] [Requesting program interpreter: /lib/ld-musl-mipsel-sf.so.1] [...] gcc 5.x doesn't need any fix because the musl patches already use the right value. Fixes bug #7562. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* gcc: drop gcc 4.5 specific codeThomas Petazzoni2016-03-091-9/+0
| | | | | | | | | | We have removed gcc 4.5 support since a long time, so this commit removes dead code that was only used when building a toolchain based on gcc 4.5. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* package/gcc: 4.9.x: backport a fix for libcap-ng issue on nios2Romain Naour2016-03-051-0/+49
| | | | | | | | | | | The patch is part of gcc 5.3 release. Fixes: http://autobuild.buildroot.net/results/901/90186d1fe134b804c0101554296b1235dc0ccbb0 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Sergio Prado <sergio.prado@e-labworks.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: remove 4.5.xGustavo Zacarias2016-02-289-635/+0
| | | | | | | | It's been deprecated for some time now. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> [Thomas: move option to Config.in.legacy, as noticed by Peter.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: mark 4.7.x as deprecatedGustavo Zacarias2016-02-241-0/+1
| | | | | | | | We're already using 4.9.x as default, and have 4.8.x on the lower side together with 5.x (5.3.0) on the higher side. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch/arm: add the cortex A17 variant supported by gcc 5.xEzequiel García2016-02-221-3/+6
| | | | | | | | | Add the Cortex A17 variant. This core is considered a replacement of the Cortex A12 and is supported by gcc 5 / binutils 2.25+ Suggested-by: Ross Green <greenfross@netscape.net> Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: bump ARC toolchain components to arc-2015.12Lada Trimasova2016-02-057-2/+2
| | | | | | | | | | | | | | | | | | | This change introduces newer ARC toolchain in Buildroot. That new arc-2015.12 release doesn't bring any significant changes but mostly is focused on fixes and minor improvements here and there. Most noticeable changes are: * GCC: Source update to v4.8.5 * GDB: Updated to upstream 7.10 release. You may find more info on fixes and improvements in that release at: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2015.12 Signed-off-by: Lada Trimasova <ltrimas@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: immediate changes to arc-2015.12-rc1Lada Trimasova2016-01-203-0/+286
| | | | | | | | | | | | | | | These patches solve several problems that were discovered after bumping tools to arc-2015.12-rc1. The fixes were done in development tree arc-4.8-dev and will be a part of the next release of ARC GNU tools. Once that new release happens these patches must be removed. Signed-off-by: Lada Trimasova <ltrimas@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: bump ARC toolchain components to arc-2015.12-rc1Alexey Brodkin2016-01-196-115/+2
| | | | | | | | | | | | | | | | | | | | | This change introduces newer ARC toolchain in Buildroot. Note this is the first release candidate and we'll probably see another RC before cutting the final release. That new arc-2015.12 release doesn't bring any significant changes but mostly is focused on fixes and minor improvements here and there. Most noticeable changes are: * GCC updated to v4.8.5 * GDB updated to 7.10 You may find more info on fixes and improvements in that release at: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2015.12-rc1 Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: arc-buildroot@synopsys.com Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: bump 5.x series to version 5.3.0Gustavo Zacarias2015-12-0725-17/+3
| | | | | | | 201-libgcc-remove-unistd-header.patch is upstream so remove it. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Tested-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* gcc: host-cloog is not needed for graphite support on gcc 5.xGustavo Zacarias2015-12-071-2/+8
| | | | | | | See https://gcc.gnu.org/gcc-5/changes.html Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* Merge branch 'next'Peter Korsgaard2015-12-011-0/+9
|\ | | | | | | Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
| * package/gcc: comment on why we override the generic configure commandsYann E. MORIN2015-11-231-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The explanations given in the commit log of 7d6c79 (Compile static versions of gcc libraries) do not explain why we have to provide custom configure commands, instead of just adding --enable-static to the configure options. Add a comment in the code that explains why that is so. Add a pointer to the ML archives with the explanations, too. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Jérôme Pouiller <jezz@sysmic.org> Acked-by: Jérôme Pouiller <jezz@sysmic.org> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* | gcc: fix incorrect handling of the comparison argumentsLada Trimasova2015-11-261-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes compiler error during libbroadvoice build. The comparison arguments where not correctly handled. The fix is done in development tree: https://github.com/foss-for-synopsys-dwc-arc-processors/gcc/commit/b4035128ba8f8bbbf9527f54f261a87b304ca4c5 and will be a part of the next release of ARC GNU tools. Once that new release happens this patch must be removed. Fixes: http://autobuild.buildroot.net/results/bea/beace68a19382b43370c798dcf7d2ef412f9d75e/ Signed-off-by: Lada Trimasova <ltrimas@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <peter@korsgaard.com> Acked-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* | gcc: add patches for powerpc e6500 64-bit supportArnout Vandecappelle2015-11-173-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Building with -mtune=e6500 led to build failures in glibc (probably in uclibc as well) because gcc was built for a 32-bit target even though the target tuple is powerpc64-*. This lead to a mix of 32-bit and 64-bit support and build errors like: fatal error: gnu/lib-names-32.h: No such file or directory The root cause is that the configure script is not handling e6500 correctly, because of stupid typo in the condition. Change has been submitted upstream. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Alvaro Gamez <alvaro.gamez@hazent.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* | gcc-final: hard link TARGET-cc -> TARGET-gccSteven Noonan2015-11-081-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | Doing a symlink results in incorrect behavior: $ x86_64-buildroot-linux-gnux32-cc --version ccache: error: execv of [...]/x86_64-buildroot-linux-gnux32-cc.br_real.br_real failed: No such file or directory $ x86_64-buildroot-linux-gnux32-gcc --version x86_64-buildroot-linux-gnux32-gcc.br_real (Buildroot 2015.11-git-00965-g8d89653-dirty) 5.2.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Note the double .br_real on the invocation by toolchain-wrapper. [Thomas: use 'ln -f' instead of 'cp -l', as suggested by Arnout.] Signed-off-by: Steven Noonan <steven@uplinklabs.net> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: use <pkg>_EXCLUDES, not <pkg>_TAR_EXCLUDESThomas Petazzoni2015-11-043-3/+3
| | | | | | | | | | | As reported by Steven Noonan, the variable recently introduced in the package infrastructure to exclude certain parts of an archive from being extracted is <pkg>_EXCLUDES, not <pkg>_TAR_EXCLUDES. However, the gcc code was incorrectly using <pkg>_TAR_EXCLUDES. This commit fixes that. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reported-by: Steven Noonan <steven@uplinklabs.net>
* package/gcc: use generic extract commandsYann E. MORIN2015-11-033-13/+8
| | | | | | | | | | Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: simplify musl patches for SSP supportThomas Petazzoni2015-10-184-144/+0
| | | | | | | | | | | | | Now that we are always explicitly passing gcc_cv_libc_provides_ssp, there is no longer any reason to modify the gcc configure/configure.ac to take into account the musl case. When a musl toolchain is being built, BR2_TOOLCHAIN_HAS_SSP is always 'y', and therefore gcc_cv_libc_provides_ssp=yes is always passed when building gcc-initial and gcc-final. 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>
* gcc: pass explicit gcc_cv_libc_provides_ssp also to gcc-finalThomas Petazzoni2015-10-183-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | During the gcc-initial build, we already pass gcc_cv_libc_provides_ssp=yes explicitly when SSP support will be available in the C library: at this point in time the C library is not yet built, so gcc cannot detect if it will support SSP or not. However, it turns out that there are some situations for which it is also useful to tell gcc explicitly whether the SSP support is available or not: the gcc logic to decide whether uClibc has SSP support or not is broken since uClibc-ng bumped the glibc version it pretends to be. So, this commit makes sure that we explicitly pass gcc_cv_libc_provides_ssp both to gcc-initial and gcc-final, and that we're always passing either 'yes' or 'no'. Fixes: http://autobuild.buildroot.org/results/778/778e6309ba834cc70f8243a4f6c664c0bcaeb7c5/ 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>
* gcc: use '.br_real' instead of '.real' suffix for the raw internal toolchainArnout Vandecappelle2015-10-171-6/+6
| | | | | | | | | | | | If an externally built (non-Buildroot) toolchain also wraps the toolchain executables, there is a risk that it will also use the '.real' extension. To minimise this risk, use a more buildroot-specific extension instead: '.br_real', so we can detect that the external toolchain is built using Buildroot and get to the raw toolchain binaries. [Peter: reword description] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* sparc64: fix toolchain building when C++ is enabledWaldemar Brodkorb2015-10-121-1/+1
| | | | | | | | | | Disable libsanitizer for sparc64, too. Same problem as for sparc, see https://bugs.busybox.net/show_bug.cgi?id=7951 Reported-By: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* arch: add support for mips32r6 and mips64r6 variantsVicente Olivert Riera2015-10-121-0/+8
| | | | | | | | | | | | | | | - Add support for mips32r6 and mips64r6 target architecture variants - Disable unsupported gcc versions - Disable unsupported binutils versions - Disable unsupported external toolchains - Disable unsuported C libraries - Add a hook in order to make glibc compile for MIPS R6. [Thomas: slightly tweak the glibc hack explanation, to make it hopefully clearer.] Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: backport xtensa libgcc stack unwinding fixesMax Filippov2015-10-059-0/+445
| | | | | | | | | | | | | | | | These backported patches fix the following failing uClibc-ng tests: nptl/tst-cancelx4, nptl/tst-cancelx16, nptl/tst-cancelx18, nptl/tst-cancelx20, nptl/tst-cancelx21, nptl/tst-cleanupx1, nptl/tst-cleanupx3, nptl/tst-oncex3, nptl/tst-oncex4. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: sort the patches before they are hashedArnout Vandecappelle2015-10-041-2/+2
| | | | | | | | | | $(wildcard ...) in make doesn't sort the files, so the order of the hashed files is not predictable. Therefore, the ccache hash could change from one build to another. We don't want that, so sort the files explicitly. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* xtensa: switch from text-section-literals to auto-litpoolsMax Filippov2015-10-041-3/+3
| | | | | | | | | | | | | | Now that both binutils and gcc support auto-litpools use that option instead of text-section-literals to be able to compile huge functions. Fixes: http://autobuild.buildroot.net/results/dd384fe0ef02a4205bea66a4a16ca2062afe53b4/ http://autobuild.buildroot.net/results/87dd357a4b883ea3cd75546b3d63c4c28245beee/ http://autobuild.buildroot.net/results/b5bca00dec1ecb118c7fb9c10dee74c94809c831/ and many others. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: backport mauto-litpools xtensa optionMax Filippov2015-10-043-0/+870
| | | | | | | | | | | | | | | With support from assembler this option allows compiling huge functions, where single literal pool at the beginning of a function may not be reachable by L32R instructions at its end. Currently assembler --auto-litpools option cannot deal with literals used from multiple locations separated by more than 256 KBytes of code. Don't turn constants into literals, instead use MOVI instruction to load them into registers and let the assembler turn them into literals as necessary. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: remove the --with-pkgversion option from the ccache hashArnout Vandecappelle2015-10-041-2/+4
| | | | | | | | | | | | | One of the gcc configure options that we hash for ccache is --with-pkgversion which is set to something like Buildroot 2015.11-git-00426-ge7e7e4f - i.e., it will change with every buildroot commit. That's obviously not wanted, so substitute this away. Also add a \n to the printf so the output is a bit more readable. [Peter: update documentation to match] Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* ccache: support changing the output directoryArnout Vandecappelle2015-10-041-1/+3
| | | | | | | | | | | | | | | | | | | | When building in a different output directory than the original build, there will currently be a lot of ccache misses because in many cases there is some -I/... absolute path in the compilation. Ccache has an option CCACHE_BASEDIR to substitute absolute paths with relative paths, so they wil be the same in the hash (and in the output). Since there are some disadvantages to this path rewriting, it is made optional as BR2_CCACHE_USE_BASEDIR. It defaults to y because the usefulness of ccache is severely reduced without this option. In addition to CCACHE_BASEDIR, we also substitute away the occurences of $(HOST_DIR) in the calculation of the compiler hash. This is done regardless of the setting of BR2_CCACHE_USE_BASEDIR because it's quite harmless. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* ccache: use mtime for external toolchain, CONF_OPTS for internal toolchainArnout Vandecappelle2015-10-041-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our current ccache disables hashing of the compiler executable itself, because using the default 'mtime' doesn't work in buildroot: we always rebuild the compiler, so the mtime is always different, so the cache always misses. However, in the current situation, if a user changes the compiler configuration (which would result in the compiler generating different object files than before) and does 'make clean all', ccache may in fact reuse object files from the previous run. This rarely gives problems, because (1) the cache expires quite quickly (it's only 1GB by default), (2) radically changing compiler options will cause cache misses because different header files are used, (3) many compiler changes (e.g. changing -mtune) have little practical effect because the resulting code is usually still compatible, (4) we currently don't use CCACHE_BASEDIR, and almost all object files will contain an absolute path (e.g. in debug info), so when building in a different directory, most of it will miss, (5) we do mostly build test, and many of the potential problems only appear at runtime. Still, when ccache _does_ use the wrong cached object files, the effects are really weird and hard to debug. Also, we want reproducible builds and obviously the above makes builds non-reproducible. So we have a FAQ entry that warns against using ccache and tells the user to clear the cache in case of problems. Now that ccache is called from the toolchain wrapper, it is in fact possible to at least use the 'mtime' compiler hash for the external toolchain and for the host-gcc. Indeed, in this case, the compiler executable comes from a tarball so the mtime will be a good reference for its state. Therefore, the patch (sed script) that changes the default from 'mtime' to 'none' is removed. For the internal toolchain, we can do better by providing a hash of the relevant toolchain options. We are only interested in things that affect the compiler itself, because ccache also processes the header files and it doesn't look at libraries because it doesn't cache the link step, just compilation. Everything that affects the compiler itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of course, also the compiler source itself is relevant, so the source tarball and all the patches are included in the hash. For this purpose, a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced. The following procedure tests the ccache behaviour: Use this defconfig: BR2_arm=y BR2_CCACHE=y make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" Now make menuconfig, change variant into BR2_cortex_a9 make clean; make readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os -> Tag_CPU_name: "ARM926EJ-S" should be "Cortex-A9" After this commit, it is "Cortex-A9". Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Danomi Manchego <danomimanchego123@gmail.com> Cc: Károly Kasza <kaszak@gmail.com> Cc: Samuel Martin <s.martin49@gmail.com> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* gcc: remove unsafe patch check (poison system dirs) patchArnout Vandecappelle2015-10-046-1050/+0
| | | | | | | | | | | | | | Now that the calls to gcc always pass through the toolchain wrapper, it is no longer necessary to patch gcc to support poisoning. This does have the disadvantage that there is no unsafe path check for libc, libgcc and libstdc++ (all of these are built before the wrapper exists). But we can assume that the toolchain components themselves should be pretty safe. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
OpenPOWER on IntegriCloud