summaryrefslogtreecommitdiffstats
path: root/toolchain
AgeCommit message (Collapse)Author
2014-12-21toolchain: get rid of -pipe from optimisationsYann E. MORIN
-pipe is causing some build failures in Linux kernel >= 3.17. Also, nowadays, using -pipe does not gain as much as it used to back in the days: Measurements made with a 3.16.7 Linux kernel: make linux-depends time sh -c 'make linux-build >/dev/null 2>&1' Without -pipe: 716.32user 54.44system 3:42.12elapsed 346%CPU 721.22user 54.47system 3:41.81elapsed 349%CPU 722.44user 54.00system 3:42.13elapsed 349%CPU 721.03user 53.81system 3:41.92elapsed 349%CPU 713.21user 53.63system 3:40.51elapsed 347%CPU 706.67user 52.42system 3:38.40elapsed 347%CPU 714.40user 53.18system 3:40.16elapsed 348%CPU 706.01user 53.09system 3:37.87elapsed 348%CPU 705.98user 53.01system 3:38.03elapsed 348%CPU 714.17user 53.55system 3:39.98elapsed 348%CPU Average: 3:40.29elapsed With -pipe: 720.13user 53.90system 3:41.98elapsed 348%CPU 713.38user 53.69system 3:40.44elapsed 347%CPU 711.60user 52.81system 3:39.06elapsed 348%CPU 708.66user 53.09system 3:38.59elapsed 348%CPU 711.76user 53.00system 3:38.48elapsed 350%CPU 717.85user 53.97system 3:41.77elapsed 348%CPU 716.77user 53.77system 3:40.91elapsed 348%CPU 717.48user 53.65system 3:41.24elapsed 348%CPU 721.44user 55.67system 3:43.45elapsed 347%CPU 724.61user 55.63system 3:43.35elapsed 349%CPU Average: 3:40.93elapsed The delta is well in the measurement noise. Just get rid of it. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> 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>
2014-12-11Rename BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBSThomas Petazzoni
Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed from "prefer static libraries when possible" to "use only static libraries". The former semantic didn't make much sense, since the user had absolutely no control/idea of which package would use static libraries, and which packages would not. Therefore, for quite some time, we have been starting to enforce that BR2_PREFER_STATIC_LIB should really build everything with static libraries. As a consequence, this patch renames BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS, and adjust the Config.in option accordingly. This also helps preparing the addition of other options to select shared, shared+static or just static. Note that we have verified that this commit can be reproduced by simply doing a global rename of BR2_PREFER_STATIC_LIB to BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-12-11toolchain-external: instrument wrapper to warn about unsafe pathsThomas Petazzoni
The CodeSourcery toolchains have a very interesting feature: they warn the user when an unsafe header or library path is used, i.e a path that will lead host headers or libraries to leak into the build. This commit adds a similar functionality into our external toolchain wrapper, so that it can be used with all external toolchains, and can also be tuned as needed. By default, the external toolchain wrapper now gives warnings such as: arm-linux-gcc: WARNING: unsafe header/library path used in cross-compilation: '-I /usr/foo' arm-linux-gcc: WARNING: unsafe header/library path used in cross-compilation: '-L /usr/bleh' but the compilation continues successfully. One can then easily grep in his build log to search for occurences of this message. Optionally, if BR_COMPILER_PARANOID_UNSAFE_PATH is defined in the environment to a non empty value, the external wrapper will instead error out and abort the compilation. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Romain Naour <romain.naour@openwide.fr> Tested-by: Romain Naour <romain.naour@openwide.fr>
2014-12-08toolchain: add 3.18 choice for headersGustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-12-07toolchain-external: add CodeSourcery MIPS 2014.11, remove 2013.05Vicente Olivert Riera
- Add CodeSourcery MIPS 2014.11 toolchain - Remove CodeSourcery MIPS 2013.05 toolchain - Update the hash file Toolchain datasheet: https://sourcery.mentor.com/GNUToolchain/release2935?@template=datasheet Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-07toolchain-external: fix the help message for CodeSourcery MIPSVicente Olivert Riera
- Fix the help message for CodeSourcery MIPS toolchains - Add a hash file Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-11-27toolchain/external: fix building the wrapper on MIPSYann E. MORIN
Some crazy folks use MIPS machines as build machines. ;-) On MIPS, the only acceptable hash-style is 'sysv', because the MIPS ABI defines that the GOT ordering to be the same as the symbols ordering, while GNU hash requires symbols to be sorted by their hash. Looking at binutils' code, it seems that only MIPS suffers from that limitation. Currently, we force the toolchain wrapper to be linked with both hash styles, which breaks on MIPS. So, fix that by singling out MIPS, and use sysv in that case, and both otherwise. Reported-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-21toolchain: do not allow locale generation when locale support is not availableThomas Petazzoni
When the C library being used is uClibc, the locale support can be disabled. In this case, it does not make sense to show the "Generate locales" option. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-21toolchain: do not allow BR2_GENERATE_LOCALE with muslThomas Petazzoni
Generating locales is possible in two situations: - With the internal toolchain backend, when the uClibc library is used. With uClibc, locales are generated at build time of the C library, so with uClibc it's only possible with the internal toolchain backend. - With either the internal or external toolchain backend when the glibc library is used. With glibc, locales can be generated afterwards, using the host-localedef utility. Until we had the musl C library supported in the internal toolchain backend, the condition: BR2_TOOLCHAIN_BUILDROOT || BR2_TOOLCHAIN_USES_GLIBC was correct to capture the above two situations. Now that we have musl support in the internal toolchain backend, then BR2_TOOLCHAIN_BUILDROOT is incorrect, and we should use BR2_TOOLCHAIN_BUILDROOT_UCLIBC instead. Basic locale support in musl has appeared in musl 1.1.4, but we are not yet capable of generating the locale files for musl. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-11toolchain-external: update Linaro toolchainsThomas Petazzoni
Bump the ARM, ARMeb and AArch64 Linaro toolchains from 14.08 to 14.09. We can't bump to 14.10, because they completely changed the toolchains and they are now completely broken: they switched from Crosstool-NG to a new build tool to generate the toolchain, and now the sysroot handling is completely borked. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-07toolchain-external: do not use BR2_GCC_TARGET_TUNE anymoreThomas Petazzoni
Since the BR2_GCC_TARGET_TUNE value is always empty now, there is no longer a point in using it in the external toolchain logic. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-06toolchain-external: use BR2_ARM_CPU_ARM* optionsThomas Petazzoni
Refactor the toolchain-external Config.in file to use the BR2_ARM_CPU_ARM*. All of the changes are purely mechanical, except for the Arago ARMv5 toolchain: it had a 'depends on BR2_GCC_TARGET_ARCH != "armv5t"', but armv5t was not a possible value for BR2_GCC_TARGET_ARCH. Since the toolchain is ARMv5TE, the only ARM architectures we need to exclude are ARMv4 and ARMv4T. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-25system/skeleton: make nsswitch install conditionalGustavo Zacarias
Don't blindly install the /etc/nsswitch.conf file, it's useless for toolchains that aren't (e)glibc-based and misleading. Make the installation conditional on a (e)glibc toolchain. [Thomas: use $(INSTALL) instead of cp.] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-10-23package: indentation cleanupJerzy Grzegorek
Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-10-09toolchain: external 3.17 headers typo fixKaroly Kasza
Commit 2d312b7b61c98716535513a2743a85d4d7e8a084 had a typo "." instead of "_" in BR2_TOOLCHAIN_HEADERS_AT_LEAST_3.17. This made selecting 3.17 as custom external headers version impossible. Signed-off-by: Karoly Kasza <kaszak@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-07.mk files: bulk aligment and whitespace cleanup of assignmentsThomas De Schampheleire
The Buildroot coding style defines one space around make assignments and does not align the assignment symbols. This patch does a bulk fix of offending packages. The package infrastructures (or more in general assignments to calculated variable names, like $(2)_FOO) are not touched. Alignment of line continuation characters (\) is kept as-is. The sed command used to do this replacement is: find * -name "*.mk" | xargs sed -i \ -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*$#\1 \2#' -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\]\+\)$#\1 \2 \3#' -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\s*\([^\\ \t]\+\s*\\\)\s*$#\1 \2 \3#' -e 's#^\([A-Z0-9a-z_]\+\)\s*\([?:+]\?=\)\(\s*\\\)#\1 \2\3#' Brief explanation of this command: ^\([A-Z0-9a-z_]\+\) a regular variable at the beginning of the line \([?:+]\?=\) any assignment character =, :=, ?=, += \([^\\]\+\) any string not containing a line continuation \([^\\ \t]\+\s*\\\) string, optional whitespace, followed by a line continuation character \(\s*\\\) optional whitespace, followed by a line continuation character Hence, the first subexpression handles empty assignments, the second handles regular assignments, the third handles regular assignments with line continuation, and the fourth empty assignments with line continuation. This expression was tested on following test text: (initial tab not included) FOO = spaces before FOO = spaces before and after FOO = tab before FOO = tab and spaces before FOO = tab after FOO = tab and spaces after FOO = spaces and tab after FOO = \ FOO = bar \ FOO = bar space \ FOO = \ GENIMAGE_DEPENDENCIES = host-pkgconf libconfuse FOO += spaces before FOO ?= spaces before and after FOO := FOO = FOO = FOO = FOO = $(MAKE1) CROSS_COMPILE=$(TARGET_CROSS) -C AT91BOOTSTRAP3_DEFCONFIG = \ AXEL_DISABLE_I18N=--i18n=0 After this bulk change, following manual fixups were done: - fix line continuation alignment in cegui06 and spice (the sed expression leaves the number of whitespace between the value and line continuation character intact, but the whitespace before that could have changed, causing misalignment. - qt5base was reverted, as this package uses extensive alignment which actually makes the code more readable. Finally, the end result was manually reviewed. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Cc: Yann E. Morin <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-10-06toolchain: add 3.17 choice for headersGustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-16toolchain-external: bump ARM, ARMeb and AArch64 Linaro toolchains to 14.08Thomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-16toolchain-external: remove CodeSourcery ARM 2012.03, add 2014.05Thomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-16toolchain-external: add CodeSourcery AArch64 toolchainThomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-13toolchain/musl: disable for PowerPC SPEGustavo Zacarias
It's not supported and the build breaks. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-09-01toolchain-external: Add CodeSourcery Nios-II 2014.05Ezequiel García
This new toolchain release fixes a number of issues found with the previous one. In particular, the issues with fallocate64, prlimit64 and the ill-installed linux headers seem to be fixed now. Therefore, there's not need to sanitize the headers for this toolchain and some packages should now build fine (e.g. fio). Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-08-18toolchain: drop the now-unused old BR2_TOOLCHAIN_HAS_ATOMIC_INTRINSICSYann E. MORIN
It's now been replaced with BR2_ARCH_HAS_ATOMICS, annd all packages have been changed to use that instead. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Anton Kolesov <Anton.Kolesov@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-08-18arch: add an option to specify if the arch has atomic opsYann E. MORIN
The fact that atomic operations are available is not really a specificity of the toolchain, but rather of the architecture. So, add a new option that architectures that have atomic operations can select. This in turn selects the current toolchain atomic option, until all packages have been converted, at which point the old toolchain option can be removed. Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Anton Kolesov <Anton.Kolesov@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-08-04toolchain: add 3.16 choice for headersGustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-08-03toolchain: Add config option for atomic intrinsicsAnton Kolesov
GCC has several builtin functions that implement atomic operations. Those functions are architecture specific and may not be implemented by the specific toolchain. In case of GCC for ARC those functions rely on LLOCK/SCOND instructions which are optional in ARC CPU's. If ARC CPU doesn't support those instructions but software tries to use them, then application will be aborted with Illegal instruction exception. To avoid confusion user should first specify that their CPU supports atomic extension, which will allow selection of packages that use builtin atomic functions. Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-31toolchain: linker options with a $ sign are not supportedYann E. MORIN
As reported in bug #7172 [0], setting BR2_TARGET_LDFLAGS to a value containing a $ sign can lead to unexpected results. This is because it is very hard to know when the $ sign gets evaluated: - in the Buildroot-level make - in the shell called by the Buildroot-level make - in the package's own build-system, either at configure time, in the Makefile, in a shell in the Makefile... So, it is very difficult to know how much escaping that would need. A proposal is to use a shell variable to pass such values unmolested. But it is not that simple either, since it still contains a $ sign, and there is not much certainty as to when it would be evaluated. Instead, just document this limitation, both in the help text for BR2_TARGET_LDFLAGS, and in the known-issues section in the manual. Does not really fix #7172, but at least the limitation is documented. [0] https://bugs.buildroot.org/show_bug.cgi?id=7172 Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Mike Zick <minimod@morethan.org> Reviewed-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-27toolchain: add option to copy the gconv librariesYann E. MORIN
The gconv libraries are used to translate between different character sets ('charsets', even 'csets' sometimes). Some packages need them to present text to the user (eg. XBMC Gotham). In (e)glibc they are implemented by the internal implemenation of iconv, called gconv, and are provided as dlopen-able libraries. Note that some gconv modules need extra libraries (shared by more than one gconv module), so we must, when adding a subset of modules, scan the installed modules in search of the missing libraries. [Thomas: add general explanation in expunge-gconv-modules and fix coding style.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Cc: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Cc: Eric Limpens <limpens@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-10toolchain-external: remove experimental Blackfin toolchainThomas Petazzoni
The 2014R1 toolchain is provided in two flavours by Analog Devices: one based on gcc 4.3.x, which is considered stable, and one based on gcc 4.5.x, considered experimental. In commit 5a65b8e185fab38824da5e9b7b5b9e781e31d368 ("toolchain-external: add ADI Blackfin 2014R1 toolchain, remove 2012R1") both variants were added. However, after some testing in the autobuilders, and discussion with the Analog Devices folks, it turns out that the experimental version of the toolchain is too experimental. It causes numerous build failures, and the Analog Devices folks clearly say that it's an early release and that they expect quite a few problems to show up. Therefore, this commit removes the experimental flavor and keeps only the stable variant. Note that the removal/renaming of the Config.in options is not a problem, since those options were added after the 2014.05 release. Fixes: http://autobuild.buildroot.org/results/2a9/2a9d9c332a206fdb46bc8ba022c74d23082a6312/ http://autobuild.buildroot.org/results/e1c/e1ce0c1cdd0139208dddaa8f2441ab0e3ab2385e/ http://autobuild.buildroot.org/results/993/993aca3f4719afaa4b37524f9136fb8cdc53a066/ and more. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-07-04toolchain/helpers.mk: update check_arm_abi commentBaruch Siach
Since commit b2e88073dbf (toolchain: check ARM EABI vs. EABIhf for external toolchains), check_arm_abi accepts a second parameter. Update the comment accordingly. Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-07-04toolchain/helpers.mk: don't discard check_arm_abi stderrBaruch Siach
Since we only need to know whether the compiler runs successfully, and stderr is empty for the success case, there is no need to redirect stderr to /dev/null. Moreover, stderr output of the failing case reveals valuable information on the real failure reason. Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-14toolchain/toolchain-buildroot: migrate to virtual package infrastructureThomas De Schampheleire
This patch migrates the toolchain and toolchain-buildroot packages to the virtual package infrastructure, causing the log messages to change from: >>> toolchain undefined Downloading >>> toolchain undefined Extracting ... to >>> toolchain virtual Downloading >>> toolchain virtual Extracting ... and similar for 'toolchain-buildroot', simply because it looks nicer. At the same time, the directory names also become toolchain-virtual, toolchain-buildroot-virtual instead of the corresponding 'undefined' variants. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-14toolchain-external: add CodeSourcery PowerPC 2012.03Thomas Petazzoni
However, this toolchain is only usable for e500v2 with the SPE ABI. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Ryan Barnett <ryan.barnett@rockwellcollins.com>
2014-06-13toolchain-external: bump musl external toolchains to 1.1.1Thomas Petazzoni
And while we're at it, factorize the definition of the musl version, since it's common to the definition of the tarball names for the various supported architectures. [Peter: Adjust Config.in info to match new version] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-09toolchain-external: add ADI Blackfin 2014R1 toolchain, remove 2012R1Thomas Petazzoni
This commit adds support for two ADI Blackfin toolchains: the 'stable' 2014R1 based on gcc 4.3, and the 'experimental' 2014R1 based on gcc 4.5. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09toolchain-external: add CodeSourcery MIPS 2014.05, remove 2012.09Thomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09toolchain-external: bump Linaro AArch64 toolchain to 2014.05Thomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09toolchain-external: bump Linaro ARMeb toolchain to 2014.04Thomas Petazzoni
For some reason, there is no ARMeb toolchain available in the 2014.05 Linaro release. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09toolchain-external: bump Linaro ARM to 2014.05Thomas Petazzoni
The major changes are: switch to gcc 4.9 instead of 4.8, and switch to glibc 2.19 instead of glibc 2.18. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09toolchain-external: support only one Linaro AArch64 toolchain at a timeThomas Petazzoni
Linaro toolchains are released so frequently (every month) that it doesn't make much sense to support 3 consecutive versions. So, like we do for ARM big-endian, let's support only one version at a time. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09toolchain-external: support only one Linaro ARM toolchain at a timeThomas Petazzoni
Linaro toolchains are released so frequently (every month) that it doesn't make much sense to support 3 consecutive versions. So, like we do for ARM big-endian, let's support only one version at a time. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09toolchain-external: do not pass TOOLCHAIN_EXTERNAL_CFLAGS for kernel headers ↵Thomas Petazzoni
check When getting the sysroot used for the kernel headers version check, passing TOOLCHAIN_EXTERNAL_CFLAGS causes a problem when used with multilib toolchains, where only the main sysroot has the header files, and the other sysroots only have the libraries. Since the kernel headers version used is normally the same for all sysroots, this commit solves this problem by removing the TOOLCHAIN_EXTERNAL_CFLAGS argument when calling toolchain_find_sysroot, so that it returns the main sysroot, in which <linux/version.h> can be found for the kernel headers version check. Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09toolchain-external: apply kernel headers check to non-custom toolchainsThomas Petazzoni
Since the introduction of the kernel headers Config.in options, the external toolchain logic had a check for custom external toolchains to verify that the kernel headers version entered by the user matches the one of the toolchain. However, this check was not made for non-custom external toolchains (i.e the built-in profiles, such as Linaro, CodeSourcery and al.), making the assumption that the Buildroot developers will do the right selection. However, it is quite nice when bumping external toolchains to have this automatic kernel headers version check, to ensure we select the appropriate kernel headers version. Therefore, this commit makes the kernel headers version check applicable to non-custom external toolchains. Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-06-09toolchain: add 3.15 choice for headersGustavo Zacarias
[Thomas: fix BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_15 to select BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_14 and not itself.] Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-06-01reenable microblaze little endian for internal musl toolchainWaldemar Brodkorb
The assumption that musl libc does not support microblaze little endian mode is wrong. See http://git.musl-libc.org/cgit/musl/tree/configure line number 447-448. Tested with qemu. Just revert previous commit as suggested by Thomas Petazzoni. Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-06-01Merge branch 'next'Peter Korsgaard
Conflicts: package/gdb/Config.in.host Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-30glibc: doesn't build for PowerPC SPEGustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-30toolchain-buildroot: only allow the selection of Musl for Microblaze BEThomas Petazzoni
The Musl C library only supports Microblaze BE, not Microblaze LE, so this commit adjusts the dependencies of the toolchain-buildroot package to not allow the selection of Musl on Microblaze LE. Cc: William Welch <bvwelch@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-30toolchain-external: restrict Musl external toolchain to Microblaze BEThomas Petazzoni
As reported by William Welch <bvwelch@gmail.com>, the Musl external toolchain provided by the musl-cross project is only Microblaze big-endian. In fact, Musl seems to only support the big endian variant of the Microblaze architecture, with the microblaze-* tuple. This commit makes sure the Musl pre-built external toolchain provided by musl-cross can only be selected for a big-endian Microblaze configuration. Reported-by: William Welch <bvwelch@gmail.com> Cc: William Welch <bvwelch@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-26powerpc: add powerpc64 and powerpc64le supportCody P Schafer
This enables powerpc64 and powerpc64le. Currently, le needs at least glibc 2.19 and gcc 4.9.0. For gdb, 7.7.1 works (added in an earlier patch). [Peter: also disallow gcc 4.8 for ppc64le] Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-11-14 08:04:42 +0000