buildroot/package/gcc, branch 2015.11.1

gcc: fix incorrect handling of the comparison arguments

2015-11-26T22:27:03+00:00

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 Cc: Alexey Brodkin Cc: Anton Kolesov Cc: Thomas Petazzoni Cc: Peter Korsgaard Acked-by: Alexey Brodkin Signed-off-by: Peter Korsgaard

gcc: add patches for powerpc e6500 64-bit support

2015-11-16T23:16:03+00:00

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) Cc: Alvaro Gamez Cc: Gustavo Zacarias Signed-off-by: Peter Korsgaard

gcc-final: hard link TARGET-cc -> TARGET-gcc

2015-11-08T14:00:35+00:00

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 Acked-by: Arnout Vandecappelle (Essensium/Mind) Signed-off-by: Thomas Petazzoni

gcc: use _EXCLUDES, not _TAR_EXCLUDES

2015-11-04T07:32:39+00:00

As reported by Steven Noonan, the variable recently introduced in the package infrastructure to exclude certain parts of an archive from being extracted is _EXCLUDES, not _TAR_EXCLUDES. However, the gcc code was incorrectly using _TAR_EXCLUDES. This commit fixes that. Signed-off-by: Thomas Petazzoni Reported-by: Steven Noonan

package/gcc: use generic extract commands

2015-11-03T21:22:51+00:00

Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Cc: Vicente Olivert Riera Reviewed-by: Romain Naour Reviewed-by: Vicente Olivert Riera Tested-by: Vicente Olivert Riera Signed-off-by: Thomas Petazzoni

gcc: simplify musl patches for SSP support

2015-10-18T13:35:53+00:00

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 Reviewed-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

gcc: pass explicit gcc_cv_libc_provides_ssp also to gcc-final

2015-10-18T13:35:49+00:00

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 Reviewed-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

gcc: use '.br_real' instead of '.real' suffix for the raw internal toolchain

2015-10-17T08:50:20+00:00

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) Signed-off-by: Peter Korsgaard

sparc64: fix toolchain building when C++ is enabled

2015-10-12T21:45:01+00:00

Disable libsanitizer for sparc64, too. Same problem as for sparc, see https://bugs.busybox.net/show_bug.cgi?id=7951 Reported-By: Thomas Petazzoni Signed-off-by: Waldemar Brodkorb Reviewed-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

arch: add support for mips32r6 and mips64r6 variants

2015-10-12T19:33:56+00:00

- 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 Signed-off-by: Thomas Petazzoni