summaryrefslogtreecommitdiffstats
path: root/toolchain
Commit message (Collapse)AuthorAgeFilesLines
...
* toolchain-external: add publicly available musl toolchainsThomas Petazzoni2014-05-062-0/+57
| | | | | | | | | 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>
* toolchain-buildroot: add support for building musl toolchainsThomas Petazzoni2014-05-051-0/+10
| | | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: generate a gdbinit fileThomas Petazzoni2014-05-052-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: enable internal for aarch64Gustavo Zacarias2014-04-241-1/+1
| | | | | | | | | 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>
* toolchain: add a hidden config option to enable the toolchain packageFabio Porcedda2014-04-161-0/+6
| | | | | | | | | | | | | | | | 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>
* toolchain-external: add Linaro ARM big endian toolchainThomas Petazzoni2014-04-142-1/+36
| | | | | | | | | | 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>
* toolchain-external: bump Linaro AArch64 toolchainsThomas Petazzoni2014-04-142-18/+18
| | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: remove useless info in help text of Linaro ARM toolchainsThomas Petazzoni2014-04-141-6/+0
| | | | | | | | | | | 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>
* toolchain-external: bump Linaro ARM toolchainsThomas Petazzoni2014-04-142-24/+24
| | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: Introduce kernel headers sanitizationEzequiel García2014-04-141-0/+13
| | | | | | | | | | | | | | | | 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>
* toolchain: add option to declare toolchains affected by gcc PR 58595Thomas Petazzoni2014-04-142-0/+4
| | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* ext-toolchain-wrapper: fix typoBaruch Siach2014-04-101-1/+1
| | | | | | 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>
* support/check-kernel-headers: fix old custom toolchains without -print-sysrootYann E. MORIN2014-04-092-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* external toolchain: add 3.14 choice for kernel headersSamuel Martin2014-04-071-0/+4
| | | | | | 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>
* toolchain: print actual version of kernel headers when checkingYann E. MORIN2014-04-061-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* toolchain: control vendor part in GNU_TARGET_NAMENoam Camus2014-04-061-0/+17
| | | | | | | | | | | | | | | | 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>
* linux-headers: add 3.14, bump 3.{4, 10, 13}.x seriesGustavo Zacarias2014-04-011-0/+5
| | | | | Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* liburcu: disable build with gcc-4.8.x on ARMSamuel Martin2014-03-232-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Because of a gcc bug [1], liburcu checks for compiler version [2] and stops the build prematurely if gcc-4.8.[0-2] is detected for ARM. However a bug fix exists [3] and may be backported by ARM toolchain providers; that's what is done in Buildroot [4] or Linaro [5]. So, this change: - add a patch in liburcu to allow build with ARM gcc-4.8.2; - adds a new hidden symbol to reflect the toolchain status with regard to this bug [1]; - and controls liburcu visibility. However, a limitation of this is when the user is using a custom toolchain; that's why the bug details have been added in the liburcu help message. [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854 [2] http://git.lttng.org/?p=userspace-rcu.git;a=commitdiff;h=4b79310 [3] http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=204665 [4] http://git.buildroot.net/buildroot/commit/?id=c443c2be1768ebbdcb76c55d0a08fd7c983488c8 [5] http://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.8/revision/122147 [Peter: hide normal toolchain comment if bug, add comment explaining issue if bug] Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: Linaro AArch64 toolchains need a symlink, like ARM onesThomas Petazzoni2014-03-211-0/+8
| | | | | | | | | | | | Like ARM ones, the Linaro AArch64 toolchains expect libraries in /lib/aarch64-linux-gnu and /usr/lib/aarch64-linux-gnu, but Buildroot always installs them in /lib and /usr/lib. Therefore, this commit adds the appropriate symbolic links, just like we're already doing for Linaro ARM toolchains. Reported-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: fix musl external support on x86Thomas Petazzoni2014-03-061-1/+6
| | | | | | | | | | | | | On x86, the symbolic link ld-musl-<ARCH>.so.1 to libc.so must be ld-musl-i386.so.1 in all cases, but $(ARCH) in Buildroot might be i386, i486, i586, i686, etc. depending on the specific x86 variants being selected. This commit fixes that by creating a MUSL_ARCH variable set to i386 on x86, and to $(ARCH) on other architectures. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
* toolchain/wrapper: rename BR_DEBUG_WRAPPERYann E. MORIN2014-03-051-1/+1
| | | | | | | | | | | The user-facing variables should be prefixed with BR2_, not BR_. Also quote the variable in the manual. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* glibc: needs MMUYann E. MORIN2014-03-031-1/+2
| | | | | | | | | | | Like eglibc, glibc is only available to MMU-based architectures. Re-order select/depends to be in-line with eglibc, just above. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/external: check kernel headers version for custom toolchainYann E. MORIN2014-03-013-1/+39
| | | | | | | | | | | | | | | | | | Ensure the kernel headers version used in the custom external toolchain, or the manually-specified kernel headers version, matches exactly the one selected by the user. We do not care about the patch-level, since headers are not supposed to change between patchlevels. This applies only to kernels >= 3.0, but those are actually the ones we do care about; we treat all 2.6.x kernels as being a single version, since we do not support any 2.6 kernels for packages with kernel-dependant features. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/external/custom: add choice to select 'AT_LEAST_XXX' header versionYann E. MORIN2014-03-011-0/+78
| | | | | | | | | | | | | | | | | Select the appropriate BR2_TOOLCHAIN_HEADERS_AT_LEAST_XXX options for the external, custom toolchain backend. We try to be conservative here, and default to kernel headers 2.6.x. [Thomas: remove duplicated depends on BR2_TOOLCHAIN_EXTERNAL_CUSTOM, since the choice is already inside a if BR2_TOOLCHAIN_EXTERNAL_CUSTOM ... endif block.] Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/external/predefined: add choice to select 'AT_LEAST_XXX' header ↵Yann E. MORIN2014-03-011-0/+32
| | | | | | | | | | | | | | | | version Select the appropriate BR2_TOOLCHAIN_HEADERS_AT_LEAST_XXX options for the external, pre-defined toolchains. Also annotate those toolchain with older-than-3.0 headers. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain/common: add minimum kernel headers optionsYann E. MORIN2014-03-011-0/+59
| | | | | | | | | | | | | | | | We now have quite a few packages that depend on the kernel headers to be at least a certain version. For example, dvb-apps requires at least the 3.3 kernel headers. Add a set of options that packages can depend on, to check that the kernel headers match their required version. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain: introduce a toolchain knob for NPTLThomas Petazzoni2014-02-224-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | As our architecture support expands to a number of architectures that do not implement NPTL threading, and the number of packages that depend on NPTL specific features, it has become necessary to be able to know whether the toolchain has NPTL support or not. This commit adds a new BR2_TOOLCHAIN_HAS_THREADS_NPTL hidden Config.in option that allows packages to know whether NPTL is available or not. This hidden option is: * Automatically enabled when glibc/eglibc or musl toolchains are used, either internal or external. * Automatically enabled when an internal uClibc toolchain with NPTL support is configured. It is left disabled otherwise for internal uClibc toolchains. * Configured according to a visible Config.in option for custom external uClibc toolchains. [Peter: factor _EXTERNAL_HAS_THREADS in single if as suggested by Arnout] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* package: add toolchain dependency to every target packageFabio Porcedda2014-02-143-0/+6
| | | | | | | | | | | | | | | | | | | | | This commit makes the dependency from the target toolchain explicit. This way we can buid from command line a package that use inner-generic-package right after the configuration phase, example: make clean <package-name> Also remove TARGETS_ALL because the only purpose was to add toolchain dependency so it's superseded by this commit. To prevent circular dependency add the new variable <pkgname>_ADD_TOOLCHAIN_DEPENDENCY to avoid adding the toolchain dependency for toolchain packages. This is also a step forward supporting top-level parallel make. Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* package: add base dependency to every packageFabio Porcedda2014-02-141-1/+1
| | | | | | | | | | | | | | | | Move "dependencies" "dirs" "prepare" dependencies from "toolchain" to every package. This way we can build correctly every package right after the clean stage. As example with this commit we can build successfully the glibc right after the clean stage: make clean glibc This is also a step forward supporting top-level parallel make. Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* glibc: add 2.19 as a supported versionThomas Petazzoni2014-02-131-1/+1
| | | | | | | | | | | | | | | glibc 2.19 has been released recently (https://sourceware.org/ml/libc-alpha/2014-02/msg00224.html). This commit allows to build a toolchain with this new version. In order to allow this, we add a version selection that did not exist for glibc. We default to 2.18, which was the only supported version until now, and add an option for 2.19. For microblaze, which uses a specific glibc version, the version selection choice is not displayed. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* Rename BUILDROOT_LIBC to BR_LIBCPeter Korsgaard2014-02-041-1/+1
| | | | | | | No functional change, but internal variables should be name BR_foo, not BUILDROOT_foo (I think ..). Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* arch: add support for "jaguar" AMD CPU optimisationsAdrien Béraud2014-01-151-0/+3
| | | | | | | | | | | | | AMD Jaguar ( https://en.wikipedia.org/wiki/Jaguar_%28microarchitecture%29 ) is suddenly a popular architecture since it is used in the PS4 and the XBox One. Many embedded systems are also likely to use it in the next years. This patch adds support for GCC architecture-specific optimisations and tuning for these CPUs. These optimizations are available with GCC 4.8+. Signed-off-by: Adrien Beraud <adrien.beraud@savoirfairelinux.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: Fix ld.so naming with uClibc and EABIhf.Stefan Sørensen2014-01-151-1/+1
| | | | | | | | | Currently ld-linux-armhf.so.* is added to external libs when using an EABIhf toolchain, but this naming is not used by uClibc. Fix by adding a check for glibc. Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* deprecated handling: introduce BR2_DEPRECATED_SINCE_xxxx_xxThomas De Schampheleire2014-01-101-4/+4
| | | | | | | | | | | | | | | | | | | | | In order to keep better track of when a feature got deprecated, and hence when it can be removed, a new set of symbols BR2_DEPRECATED_SINCE_xxxx_xx is introduced. These symbols are automatically selected when BR2_DEPRECATED is selected, and thus are transparent to the user. A deprecated feature will no longer depend on BR2_DEPRECATED directly, but rather on the appropriate BR2_DEPRECATED_SINCE_xxxx_xx. If that symbol does not yet exist, it has to be created in Config.in. When removing a deprecated feature, one should also check whether this was the last feature using the BR2_DEPRECATED_SINCE_xxxx_xx symbol, in which case the latter can be removed from Config.in. A followup patch will make sure the overview is added to the list of deprecated features in the manual, so that a buildroot core developer can easily determine which features to remove in a given development cycle. Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain/external: fix wrapper by not passing conflicting flagsYann E. MORIN2014-01-091-10/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In our wrapper, we forcibly add the -march=, -mcpu= and-mtune= flags to the actual compiler, this in an attempt to always generate correct and optimised code for the target. But in some cases, the caller knows better than we do, and passes its own set, or subset of those flags. In this case, some may conflict with the ones we pass. The most prominent offender being the Linux kernel. For example, on the ARM Raspberry Pi, the Linux kernel will set the -march=armv6 flag and no -mcpu= flag, but we pass -mcpu=arm1176jzf-s, which conflicts: drivers/scsi/scsi_trace.c:1:0: warning: switch -mcpu=arm1176jzf-s conflicts with -march=armv6 switch (and so for all the files the kernel compiles, pretty messy) (note: arm1176jzf-s is not an armv6, it is an armv6zk. Yeah...) To avoid this situation, we scan our commandline for any occurence of the possibly conflicting flags. If none is found, then we add our owns. If any is found, then we don't add any of our owns. The idea behind this is that we trust the caller to know better than we do what it is doing. Since the biggest, and sole so far, offender is the Linux kernel, then this is a rather safe bet. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* package: remove the empty trailing line(s)Jerzy Grzegorek2014-01-042-2/+0
| | | | | Signed-off-by: Jerzy Grzegorek <jerzy.grzegorek@trzebnica.net> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: add support for the Blackfin 2013R1 toolchainThomas Petazzoni2013-12-312-1/+24
| | | | Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: mark Microblaze external toolchains as deprecatedThomas Petazzoni2013-12-311-0/+4
| | | | | | | | | | | The Xilinx Microblaze external toolchains that we had support for are very old, and are causing a huge number of build issues. Thanks to Spenser Gilliland, we now have support for Microblaze in the internal toolchain backend, and the autobuilders have been using the internal toolchain backend since then. Therefore, it's time to deprecate those old and unusable external toolchains. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: update Linaro AArch64 toolchainsThomas Petazzoni2013-12-312-14/+14
| | | | | | | | Add Linaro AArch64 2013.10 and Linaro AArch64 2013.11, and remove Linaro AArch64 2013.07 and Linaro AArch64 2013.08. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
* toolchain-external: update Linaro ARM toolchainsThomas Petazzoni2013-12-312-21/+21
| | | | | | | | | Add Linaro ARM 2013.10 and Linaro ARM 2013.11, and remove Linaro ARM 2013.07 and Linaro ARM 2013.08. The main change for those versions is the switch to eglibc 2.18. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* toolchain-external: add Sourcery MIPS 2013.11, remove Sourcery MIPS 2012.03Thomas Petazzoni2013-12-312-28/+28
| | | | | | | | | | | | This commit adds the support for the recently release Sourcery MIPS 2013.11 toolchain (gcc 4.8, gdb 7.6, glibc 2.18), and consequently removes the support for the Sourcery MIPS 2012.03 toolchain. While we're at it, also fix the incorrect help text related to the MIPS64 multilib selection. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
* toolchain-external: add Sourcery ARM 2013.11, remove Sourcery ARM 2011.09Thomas Petazzoni2013-12-292-17/+17
| | | | | | | | | This commit adds the support for the recently release Sourcery ARM 2013.11 toolchain (gcc 4.8, gdb 7.6, glibc 2.18), and consequently removes the support for the Sourcery ARM 2011.09 toolchain. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
* toolchain: enable microblaze toolchainSpenser Gilliland2013-12-062-3/+8
| | | | | | | | | | | | | | | | This commit allows to build an internal toolchain for the Microblaze architecture, with either glibc or eglibc. Note that we add an explicit list of architectures that are supported by uClibc, and Microblaze is not part of them, because it currently doesn't build for this architecture. [Thomas: add better commit log, add architecture dependencies on uClibc, to avoid selecting uClibc on Microblaze] Signed-off-by: Spenser Gilliland <spenser@gillilanding.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain: Allow ld64.so linkerJeremy Kerr2013-12-031-1/+1
| | | | | | | | | | The glibc dynamic linkers for ppc64 and s390x are named ld64.so.* so modify the check_glibc test to match them. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Anton Blanchard <anton@samba.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* Merge branch 'next'Peter Korsgaard2013-12-011-0/+1
|\ | | | | | | Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
| * toolchain/buildroot: default to eglibc for mips64Gustavo Zacarias2013-11-281-0/+1
| | | | | | | | | | | | | | | | uClibc only works well for O32 ABI on mips64, so default to eglibc that works just fine with N32 & N64 ABIs as well. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* | glibc/eglibc: remove reference to experimental from help textArnout Vandecappelle2013-11-191-6/+0
|/ | | | | | | | | Since 924b8739da we no longer declare glibc and eglibc support as experimental, so it shouldn't be mentioned in the help text anymore. Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-external: make sure (e)glibc isn't chosen when BR2_PREFER_STATIC_LIB=yThomas Petazzoni2013-11-111-0/+37
| | | | | | | | | | | (e)glibc doesn't support a fully statically linked userspace. Even a basic program such as Busybox fails to do authentication due to glibc loading some libraries dynamically. Therefore, we disable the possibility of using a (e)glibc toolchain when BR2_PREFER_STATIC_LIB=y. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-buildroot: make sure glibc isn't chosen when BR2_PREFER_STATIC_LIB=yThomas Petazzoni2013-11-111-0/+5
| | | | | | | | | | | (e)glibc doesn't support a fully statically linked userspace. Even a basic program such as Busybox fails to do authentication due to glibc loading some libraries dynamically. Therefore, we disable the possibility of building a glibc toolchain when BR2_PREFER_STATIC_LIB=y. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
* toolchain-buildroot: glibc and eglibc support is no longer experimentalThomas Petazzoni2013-11-111-2/+2
| | | | | | | | | The glibc and eglibc support has been introduced since a little bit of time now, I believe we can remove the "experimental" statement next to it. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
OpenPOWER on IntegriCloud