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

arch/xtensa: accept the overlay to be an URL

2017-07-09T14:58:03+00:00

It can be interesting to get the overlay from a remote server, rather than expect it to be present locally. Since that file can be any URL, we can't know its hash, so we just exclude it. Signed-off-by: "Yann E. MORIN" Signed-off-by: Max Filippov [Thomas: use DL_DIR instead of BR2_DL_DIR.] Signed-off-by: Thomas Petazzoni

arch/xtensa: allow specifying path to tarball file

2017-07-09T13:41:51+00:00

currently, specifying a custom Xtrensa core is done with two variables: - the core name - the directory containing the overlay tarball However, the core name only serves to construct the tarball name, and is not used whatsoever to configure any of the toolchain components (binutils, gcc or gdb), except through the files that are overlayed in their respective source trees. This has two main drawbacks: - the overlay file must be named after the core, - the tarball can not be compressed. Furthermore, it also makes it extremely complex to implement a download of that tarball. So, those two variables can be squeezed into a single variable, that is the complete path of the overlay tarball. Update the qemu-xtensa defconfig accordingly. Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it was previously a blind option in the last release, and there's been no release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user could have seen in any of our releases so far. Signed-off-by: "Yann E. MORIN" Cc: Gustavo Zacarias Signed-off-by: Max Filippov Signed-off-by: Thomas Petazzoni

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