summaryrefslogtreecommitdiff
path: root/toolchain
AgeCommit message (Collapse)Author
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>
2014-05-25Add support for powerpc64leJeff Bailey
This patch adds support for powerpc64le-linux-gnu. This includes needed patches to fakeroot and gmp. gmp patch is from upstream HG tree. fakeroot patch is from Ubuntu written by Adam Conrad. Signed-off-by: Jeff Bailey <jeffbailey@google.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-21toolchain-external: fix Linaro 2014.02 symlinkThomas Petazzoni
In commit cd32da8f7931af61737df293d1f8bcedaab8648e ("toolchain-external: add Linaro ARM big endian toolchain") a mistake was made, probably due to a rebase conflict that was incorrectly solved: the call to the post install staging hook that creates the necessary symbolic links for a root filesystem based on Linaro 2014.02 to work was removed. This commit reinstates this call, which should fix the problem observed by Maxime Hadjinlian while using Linaro 2014.02. Reported-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-12toolchain-external: Sourcery CodeBench ARM 2013.05 affected by PR58595Thomas Petazzoni
Fixes: http://autobuild.buildroot.org/results/6b3/6b342c2d101348e4d39285f45481e2aafa3d8b3f/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-11toolchain-external: Fix EABIhf checkStefan Sørensen
Currently the check for EABI/EABIhf toolchains looks for the Tag_ABI_VFP_args attribute in the crt1.o file which gcc adds in an EABIhf toolchain. In uClibc, however, crt1.o is not compiled from c but assembly, so the Tag_ABI_VFP_args attribute is not added in the object file. This causes the EABIhf check in the external toolchain logic to fail for uClibc-based toolchains. Fix by compiling a dummy .c file and trying to link the object against the C library. Since it is impossible to mix EABI and EABIhf code, a mismatch between the buildroot and toolchain ABI settings will be detected during this link step. Fixes bug #6842: https://bugs.busybox.net/show_bug.cgi?id=6842 [Peter: fix final 'fi'] Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> [ThomasDS: do full link iso readelf test, update commit message] Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-08toolchain: remove nommu option for MIPSGustavo Zacarias
MIPS nommu never took off, the only MIPS processors without MMU are microcontrollers and the only uclinux effort for them has non-upstream patches against very very old versions. See http://www.xiptech.com/uclinuxformips.htm Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-06toolchain/buildroot: default to uClibcGustavo Zacarias
Otherwise we're getting musl for everything except those who have a default (mips64*). Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-06toolchain-external: add publicly available musl toolchainsThomas Petazzoni
This commit adds ten toolchains based on the musl C library that are publicly available from the musl-cross project. [Peter: fix ppc prefix, only for classic ABI] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-05toolchain-buildroot: add support for building musl toolchainsThomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-05-05toolchain: generate a gdbinit fileThomas Petazzoni
This commit slightly improves the external toolchain backend, and the gdb build logic to create a file named $(STAGING_DIR)/usr/share/buildroot/gdbinit which can be used as a gdbinit file using gdb -x option. This allows gdb to automatically use the proper sysroot to find libraries. The initial insight for this patch comes from the report of Oded Hanson <OHanson@xsightsys.com>, who found an issue with the Eclipse Buildroot plugin, which was setting a solib-path in gdb, but not a sysroot. Setting a solib-path was enough to find shared libraries, but not the dynamic linker. And since Eclipse doesn't allow to set the sysroot in any other way than giving a gdbinit file, it makes sense to have Buildroot generate a gdbinit file (which can be used in other situations than Eclipse). To achieve this, this commit introduces a gen_gdbinit_file helper in toolchain/helpers.mk, and uses it for the internal toolchain and external toolchain backends. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [ThomasDS: minor updates in commit message] Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-04-24toolchain: enable internal for aarch64Gustavo Zacarias
Enable the internal toolchain backend for aarch64. Tested with arm_foundationv8_defconfig and ARMs foundation v8 emulator. Both glibc & eglibc work. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-04-16toolchain: add a hidden config option to enable the toolchain packageFabio Porcedda
The usual way to enable a package using the package infrastructure is to use a config option so instead to add the toolchain package to the TARGETS variable in the Makefile add a config option like all the other toolchain packages. [Thomas: remove comment that no longer made sense in the main Makefile, and add a comment above the new hidden Config.in option to explain what it is useful for.] Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Yann E. MORIN <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14toolchain-external: add Linaro ARM big endian toolchainThomas Petazzoni
Linaro has started to release ARM big endian toolchains, so we integrate this toolchain in the external toolchain logic of Buildroot. Since ARM big endian is probably going to be a lot more uncommon than ARM little endian, we will only support one version at a time of this toolchain. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14toolchain-external: bump Linaro AArch64 toolchainsThomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14toolchain-external: remove useless info in help text of Linaro ARM toolchainsThomas Petazzoni
The information "To use this toolchain, you must disable soft float usage." which was visible in the help text of Linaro toolchains is no longer useful, since those toolchains are only visible when the ARM EABIhf ABI is selected, which by design is not compatible with soft-float. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2014-04-14toolchain-external: bump Linaro ARM toolchainsThomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14toolchain-external: Introduce kernel headers sanitizationEzequiel García
The Nios-II Sourcery external toolchain (the only Nios-II we currently support) exports broken kernel headers. In particular, these kernels should be exported using the "headers_install" rule which applies a set of fixes on the kernel headers so they are suitable for userspace usage. In order to fix this, add a post-install hook to perform the header fixes ourselves. The result is equivalent to apply the "headers_install" rule. Fixes: http://autobuild.buildroot.net/results/c32/c32ad4bac5f651502e551f7733f702afaa0e742a/ Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-14toolchain: add option to declare toolchains affected by gcc PR 58595Thomas Petazzoni
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-10ext-toolchain-wrapper: fix typoBaruch Siach
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-04-09support/check-kernel-headers: fix old custom toolchains without -print-sysrootYann E. MORIN
Old toolchains, with old gcc that do not support -print-sysroot, break the kernel-headers version check script: it fails to find the sysroot of the toolchain, and thus ends up including the host's linux/version.h. Most of the time, this will break early, since the host's kernel headers will not match the toolchain settings. But it can happen that the check is succesful, although the configuration of the toolchain is wrong: - the custom toolchain has kernel headers vX.Y - the user selected vX.Z (Z!=Y) - the host has headers vX.Y In this case, the check passes OK, but the build of some packages later on will break (which is exactly what those _AT_LEAST_XXX options were added to avoid). Fix that by passing the sysroot to the check script, instead of the cross compiler. We get the sysroot as thus: - for custom toolchains, we use the macro toolchain_find_sysroot. We can do that, because we already have a complete sysroot with libc.a at that time. - for internal toolchain using a custom kernel headers version, we just use $(STAGING_DIR). We can't use the macro as for custom toolchains above, because at the time we install the kernel headers, we do not yet have a complete sysroot with a libc.a. But we can just use $(STAGING_DIR), since we're only interested in the kernel headers. For all other types of toolchains, we already have the _AT_LEAST_XXX options properly set, so we need not add a check in this case. Fixes: http://autobuild.buildroot.net/results/f33/f331a6eff0b0b93c73af52db3a6b43e4e598577e/ http://autobuild.buildroot.net/results/a57/a5797c025bec50c10efdcff74945aab4021d05e4/ [...] [Thanks to Thomas for pointing out the toolchain_find_sysroot macro!] Signed-off-by: "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-04-07external toolchain: add 3.14 choice for kernel headersSamuel Martin
Signed-off-by: Samuel Martin <s.martin49@gmail.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-04-06toolchain: print actual version of kernel headers when checkingYann E. MORIN
Since we introduced the _AT_LEAST_XXX for the kernel headers, people using pre-built custom toolchain now have to specify the version of the kernel headers their custom toolchain uses. So, when we detect that there is a mismatch between the selection in the menuconfig, and the actual version of the headers, we currently only bail out with a terse message "Incorrect selection of kernel headers". This could be confusing some, and getting the version of the headers used by the toolchain is not trivial (well, it's very easy, but not trivial.) This patch changes the way we report the error by moving the message into the test-code, and by printing the expected and actual versions of the kernel headers. BUT! To get this pretty error message, we need to run the test-program, so we can not use the cross-toolchain, we have to use the native one. BUT! The native one has its own linux/version.h header, so we can not simply include it. So, we ask the cross-compiler where its default sysroot is, and use that to then force-feed the cross linux/version.h to the native toolchain. [Thomas: augment commit log with a message provided by Yann, fix coding style to not have spaces after opening parenthesis and before closing parenthesis, reformatted the message "Incorrect selection..." to make it fit on one line.] Reported-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-04-06toolchain: control vendor part in GNU_TARGET_NAMENoam Camus
This option allows to customize the "vendor" part of the toolchain tuple, where the toolchain tuple has the form <arch>-<vendor>-<os>-<libc>. Use this option in situations where gcc might make different decisions based on the vendor part of the tuple. [Thomas: move the config option in a slightly different place, so that it does not appear between the C library selection and the C library options.] Signed-off-by: "Noam Camus" <noamc@ezchip.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-02 09:14:59 +0000