buildroot/package/gcc/gcc-initial, branch 2017.05

package/gcc: use the Xtensa variables

2017-03-26T13:49:45+00:00

... instead of re-computing them over-and-over-again. Signed-off-by: "Yann E. MORIN" Cc: Thomas Petazzoni Signed-off-by: Max Filippov Signed-off-by: Thomas Petazzoni

gcc: the special workaround for ARC is no longer required

2016-11-23T22:16:41+00:00

It seems with the change to gcc 6.x based toolchain this workaround is no longer required. Tested with an arc hs toolchain. Signed-off-by: Waldemar Brodkorb Acked-by: Alexey Brodkin Signed-off-by: Thomas Petazzoni

toolchain/wrapper: fix 'reinstall'

2016-10-24T21:02:33+00:00

toolchain-wrapper was not reinstalled. So rules toolchain-external-reinstall, gcc-initial-reinstall, gcc-final-reinstall didn't work as expected. In add, normalize variable name: s/TOOLCHAIN_BUILD_WRAPPER/TOOLCHAIN_WRAPPER_BUILD/ Signed-off-by: Jérôme Pouiller Signed-off-by: Thomas Petazzoni

gcc: rename option for ARC gcc

2016-09-20T19:19:24+00:00

The ARC gcc version is now based on gcc 6.x and no longer gcc 4.8.x, which makes the option BR2_GCC_VERSION_4_8_ARC a bit irrelevant, as is the prompt of this option. This commit therefore renames this option to BR2_GCC_VERSION_ARC, and adjust its prompt as well. 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: 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 toolchain wrapper

2015-10-04T16:22:20+00:00

We have a toolchain wrapper for external toolchain, but it is also beneficial for internal toolchains, for the following reasons: 1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the compiler even if a package's build system doesn't honor CFLAGS. 2. It allows us to do the unsafe path check (i.e. -I/usr/include) without patching gcc. 3. It makes it simpler to implement building each package with a separate staging directory (per-package staging). 4. It makes it simpler to implement a compiler hash check for ccache. The wrapper is reused from the external toolchain. A third CROSS_PATH_ option is added to the wrapper: in this case, the real executable is in the same directory, with the extension .real. The creation of the simple symlinks is merged with the creation of the wrapper symlinks, otherwise part of the -gcc-ar handling logic would have to be repeated. The complex case-condition could be refactored with the one for the external toolchain, but then it becomes even more complex because they each have special corner cases. For example, the internal toolchain has to handle *.real to avoid creating an extra indirection after host-gcc-{final,initial}-rebuild. Instead of creating the .real files, it would also have been possible to install the internal toolchain in $(HOST_DIR)/opt, similar to what we do for the external toolchain. However, then we would also have to copy things to the sysroot and do more of the magic that the external toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much simpler. Note that gcc-initial has to be wrapped as well, because it is used for building libc and we want to apply the same magic when building libc. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) Cc: Fabio Porcedda Cc: Jérôme Oufella Reviewed-by: Romain Naour Signed-off-by: Peter Korsgaard

package/gcc: fix ARC failure to build in 2 phases.

2015-07-02T21:44:28+00:00

When working with GCC initial at override source dir mode the HOST_GCC_INITIAL_POST_PATCH_HOOKS is not called and compilation failes. The solution is to use HOST_GCC_INITIAL_POST_RSYNC_HOOKS since this hook is being called at override source dir mode. Signed-off-by: Tal Zilcer Reviewed-by: "Yann E. MORIN" Signed-off-by: Thomas Petazzoni

package/gcc: add hashes

2015-04-23T21:01:47+00:00

Signed-off-by: "Yann E. MORIN" Signed-off-by: Arnout Vandecappelle (Essensium/Mind) cc: Thomas Petazzoni Cc: Gustavo Zacarias Acked-by: Arnout Vandecappelle (Essensium/Mind) Tested-by: Gustavo Zacarias Signed-off-by: Thomas Petazzoni