summaryrefslogtreecommitdiffstats
path: root/package/gcc
Commit message (Collapse)AuthorAgeFilesLines
...
* 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>
* gcc: use toolchain wrapperArnout Vandecappelle2015-10-043-8/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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) <arnout@mind.be> Cc: Fabio Porcedda <fabio.porcedda@gmail.com> Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* host-gcc-final: don't install a potentially dead symlinkArnout Vandecappelle2015-09-201-3/+0
| | | | | | | | | | | | | | | | | | gcc used to be installed into $(HOST_DIR)/usr/$(GNU_TARGET_NAME) but since gcc 4.9 this is no longer the case. Therefore, the cc -> gcc symlink that is created in that we create in that directory is dead. There don't seem to have been any problems due to the missing gcc and cc in $(HOST_DIR)/usr/$(GNU_TARGET_NAME), things seems to build fine without it. The cc -> gcc symlinks in general should not be needed anyway, since we always pass the appropriate CC variable to the package build system. Therefore, let's remove the cc -> gcc symlink in $(HOST_DIR)/usr/$(GNU_TARGET_NAME) - also for pre-4.9 gcc versions. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: add missing NIOS-II patch after bump to 4.9.3Thomas Petazzoni2015-08-081-0/+12
| | | | | | | | | | | | | When gcc 4.9.x was bumped from 4.9.2 to 4.9.3 in commit 2fed00ea1eaeca952f872120af79a46f39b0868c, patch 920-libgcc-remove-unistd-header.patch was removed with the argument that it had been applied upstream. However, it is not the case, and the patch continues to apply fine on gcc 4.9.3, and is actually needed to make gcc build properly on NIOS-II. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: select the appropriate BR2_TOOLCHAIN_GCC_AT_LEAST_* optionThomas Petazzoni2015-08-051-0/+7
| | | | | | | | | | This commit wires up the gcc version dependency mechanism in the internal toolchain backend by making the gcc version choice in the gcc package Config.in.host select the appropriate BR2_TOOLCHAIN_GCC_AT_LEAST_* option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
* binutils: rename config optionGustavo Zacarias2015-07-281-1/+1
| | | | | | | | Rename the binutils configuration option to match that one used by gcc where the patchlevel is explicitly left out. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* package/gcc (4.7): backport PR56780 patchesRomain Naour2015-07-271-0/+244
| | | | | | | Reported-by: Anthony Viallard <viallard@syscom-instruments.com> Signed-off-by: Romain Naour <romain.naour@openwide.fr> Cc: Anthony Viallard <viallard@syscom-instruments.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* package/gcc: fix gcc 4.7 build with gcc5Romain Naour2015-07-271-0/+42
| | | | | | | | | | | gcc 4.7 doesn't build with gcc5. Patch is from DragonFlyBSD github [1] [1] https://github.com/DragonFlyBSD/DPorts/issues/136 Signed-off-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* package/gcc: fix libgcc build for xtensaMax Filippov2015-07-241-0/+7
| | | | | | | | | | | | xtensa libgcc can't be built with -mtext-section-literals flag, now coming from TARGET_CFLAGS, because it needs to emit literals to .init/.fini sections, which is not currently supported. Filter -mtext-section-literals flag out of GCC_COMMON_TARGET_CFLAGS. Suggested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* package/gcc: fix typo for CFLAGS_FOR_TARGETRomain Naour2015-07-231-1/+1
| | | | | | | | | CFLAGS_FOR_TARGET is initialized with GCC_COMMON_TARGET_CXXFLAGS. Signed-off-by: Romain Naour <romain.naour@openwide.fr> Cc: Alexey Brodkin <abrodkin@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: explicitly use C{XX}FLAGS_FOR_TARGET instead of --enable-target-optspaceAlexey Brodkin2015-07-221-3/+9
| | | | | | | | | | | | | | | | | | | | | | The gcc.mk file is passing --enable-target-optspace to gcc configure script, to ask for space-optimized (-Os) target libraries. However, passing this option has the effect of overriding any custom CFLAGS_FOR_TARGET or CXXFLAGS_FOR_TARGET values that may be passed. These are some situations when it is required to pass custom flags on buildong of libgcc: * Default flags "-g -Os" lead to build isses as with PowerPC on gcc 4.5 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810) * Particular CPU requires specific instructions for HW support * Deep optimizations Signed-off-by: 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> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: add support for fortranDavid Kessler2015-07-192-0/+12
| | | | | Signed-off-by: David Kessler <DJKessler@me.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: fix undefined reference to .tdataAlexey Brodkin2015-07-181-0/+42
| | | | | | | | | | | | | | | | | | | | | | This fix is done in development tree: http://github.com/foss-for-synopsys-dwc-arc-processors/gcc/commit/366cc86e4f8ff6f00f0b731dc6f78d22c7ac9e0a 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/8b22ac0dc9e3c1cd44f2fdbe5cc99a41cf77f454/ http://autobuild.buildroot.net/results/37e9c3c79e0a6aea5b89428c2226811ebb3fd611/ http://autobuild.buildroot.net/results/37e9c3c79e0a6aea5b89428c2226811ebb3fd611/ and many others. Prerequisite: "ARC: update tools to arc-2015.06 release": http://patchwork.ozlabs.org/patch/495837/ Signed-off-by: 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> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc/libmudflap: also unavailable for gcc 5.xGustavo Zacarias2015-07-181-0/+1
| | | | | Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: bump 5.x series to version 5.2.0Gustavo Zacarias2015-07-1821-5/+5
| | | | | | | | Also rename the BR2_GCC_VERSION_5_1_X symbol to BR2_GCC_VERSION_5_X to reflect this change to match the new versioning scheme. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* ARC: update tools to arc-2015.06 releaseAlexey Brodkin2015-07-185-2/+2
| | | | | | | | | | | | | | | | | | | | | | I'm happy to update GNU tools for ARC cores to the most recent arc-2015.06 release. This release brings following major improvements: * GCC: source update to v4.8.4 * GCC: C ABI compatibility between MetaWare and GNU toolchains * uClibc: support for thread local storage and Native Pthread Library (NPTL) * GDB: updated to version 7.9.1 Also a lot of fixes and improvements has been done, please refer to https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/tag/arc-2015.06 for more details. Signed-off-by: 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> Cc: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* packages: do not use TAR_STRIP_COMPONENTS, but directly --strip-componentsThomas Petazzoni2015-07-121-1/+1
| | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* Disable gcc-4.8.x + binutils-2.25 + MIPS combinationVicente Olivert Riera2015-07-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This combination causes a compilation failure of the host-gcc-final recipe like this one: /br/output/host/usr/mips-buildroot-linux-gnu/bin/ld: .libs/gload.o: relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making a shared object; recompile with -fPIC The problem is the file 'libatomic/gload.c' is compiled without -fPIC when using binutils-2.25. All gcc (with libatomic) versions below 4.9.3 are affected by this issue. Here is a summary of affected/unaffected versions in Buildroot: 4.7.x: unaffected (doesn't have libatomic) 4.8.x: affected 4.9.x: unaffected (we have 4.9.3 which is fixed) 5.1.x: unaffected The fix can be found here: https://github.com/gcc-mirror/gcc/commit/57f5c0954f95cb37f995d60167ddde06c7d6e697 However, given the following reasons... - Upstream gcc 4.8 branch is closed. - The fix is very hard to backport from 4.9 to 4.8. - This stuff is insanely sensitive and not working at all could be better than looking like it works but not quite. ...I think the best choice is to disable that combination in Buildroot. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* package/gcc: fix ARC failure to build in 2 phases.Tal Zilcer2015-07-021-0/+1
| | | | | | | | | | | 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 <talz@ezchip.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* ARC: update folders with patches for arc-2015.06-rc1 releaseAlexey Brodkin2015-07-013-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | In buildroot we maintain a couple off-the-tree patches. In particular for binutils and gcc packages. Because we have many versions of mentioned packages patches for each particular version reside in a folder which name matches full version name of the package. For example we used to have patches for binutils distributed as part of arc-2014.12 tools in folder ""package/binutils/arc-2014.12". Now with bump of ARC tools version we need to rename folder with patches to "arc-2015.06-rc1". The same applies to gcc. Should fix http://autobuild.buildroot.net/results/2b2/2b27a4a64c0b225ae479ecfccf7a97f5ea95598c/ As discussed before it's not possible to reproduce reported problem on recent Fedora 21/22 distros (at least we know about them) but I may confirm that patches were applied fine and everything was built well. Hopefully reported build failure goes away now. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Cc: Romain Naour <romain.naour@openwide.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* ARC: switch to RC1 of upcoming arc-2015.06 toolsAlexey Brodkin2015-06-282-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Even though this is only RC1 it's been heavily used internally so it should not be any worse than existing arc-2014.12. Moreover this relase (and so its RC1) finally delivers support of NPTL for ARC in uClibc. That's why it would be good to allow interested users to start trying it (for example WebKit and apps that use WebKit could be successfully built and run) also it will be helpful to run that new toolchain through autobuilder in attempt to find any hidden regressions so we have a solid toolchain for release. If there's an interest in that patch more patches will follow with subsequent RCs and essentially on appearence or relese Buildroot will be updated with it. 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 4.9.x series to version 4.9.3Gustavo Zacarias2015-06-2816-347/+258
| | | | | | | | | | Drop 110-pr64896.patch and 920-libgcc-remove-unistd-header.patch since they're upstream. Tweak 850-libstdcxx-uclibc-c99.patch for this new release. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* gcc: bump 4.8.x versionPeter Korsgaard2015-06-2416-3/+3
| | | | Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* gcc: switch to gcc 4.9 as the default versionThomas Petazzoni2015-06-231-2/+1
| | | | | | | | Now that we have added gcc 5.1, it's time to make gcc 4.9 the default version used in Buildroot. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* gcc: add support for gcc 5.1Thomas Petazzoni2015-06-2321-0/+1623
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds support for gcc 5.1 in Buildroot. In terms of gcc patches, compared to gcc 4.9.x: * Kept as is, sometimes after minor adjusments: 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 850-libstdcxx-uclibc-c99.patch 860-cilk-wchar.patch * Dropped: 110-pr64896.patch 111-pr65730.patch * Split in multiple parts: 900-musl-support.patch The patches from Crosstool-NG for muls support are used instead of one single patch. * Renamed: 910-gcc-poison-system-directories.patch to 200-gcc-poison-system-directories.patch 920-libgcc-remove-unistd-header.patch to 201-libgcc-remove-unistd-header.patch Since the 9xx part of the series is now used by the various musl related patches. We have tested the following configurations, with a minimal Busybox system: * ARM, uClibc-ng * ARM, glibc * ARM, musl * x86, uClibc-ng and uClibc 0.9.33.2 * x86, glibc * x86, musl All of the configurations built fine. All the configurations boot fine in Qemu, except x86/uClibc (either ng or 0.9.33.2), it segfaults when running init: devtmpfs: mounted Freeing unused kernel memory: 300K (c1389000 - c13d4000) init[1]: segfault at 0 ip b77708c1 sp bfa9bb0c error 4 in ld-uClibc-0.9.33.2.so[b776c000+6000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b We'll give some time for the uClibc developers to fix the problem before taking other measures in Buildroot to exclude gcc 5.1 from a x86/uClibc configuration. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* gcc/gcc-final: install libatomic via HOST_GCC_FINAL_GCC_LIB_DIRGustavo Zacarias2015-06-061-2/+2
| | | | | | | Otherwise it's a no-op for sh4. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
OpenPOWER on IntegriCloud