summaryrefslogtreecommitdiff
path: root/toolchain/toolchain-common.in
AgeCommit message (Collapse)Author
2016-12-12toolchain: add 4.9.x choice for headersFabio Estevam
Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-25toolchain: configs: improve toolchain config readabilityPetri Gynther
Add (or move) comment lines in toolchain-related Config.in files to improve readability of the toolchain config section. Source linux-headers/Config.in.host after toolchain-buildroot items. For toolchain-buildroot case, the config file now looks like this: * * Toolchain * * * Toolchain Buildroot Options * * * Kernel Header Options * * * uClibc Options * * * Binutils Options * * * GCC Options * * * Host GDB Options * * * Toolchain Generic Options * Signed-off-by: Petri Gynther <pgynther@google.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-09-12linux-headers: allow specifying 4.8 as kernel header versionFabio Estevam
Even though 4.8 is not released yet, some people may want to build a system using the 4.8-rc kernel, and point to the kernel sources as the kernel headers to use for the toolchain. In order to make this possible, this commit adds support for specifying 4.8 as the kernel headers version, in both the internal and external toolchain logic. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> [Thomas: remove support for 4.8 headers selection, and rework commit log.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-03system: move locale purging options to the "System configuration" menuThomas Petazzoni
The options to purge locales and to generate locale data are currently located in the toolchain menu. However, these options are not really related to the toolchain per-se, they are more system-level configuration options, much like the timezone selection option we already have in the "System configuration" menu. Therefore, it makes more sense to have the locale-related options in the "System configuration" menu as well. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-03toolchain: reduce the list of locales to keep by defaultThomas Petazzoni
Our current list of locales to keep by default is "C en_US de fr". It doesn't make much sense to keep "de" and "fr" more than any other language. So let's keep only the "C" and "en_US" locales by default, and leave it to the user to specify other locales to keep if needed. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-03toolchain: purge locales by defaultThomas Petazzoni
Our current default is to keep all locales installed in /usr/share/locale/. However, in practice, those locales take up a significant amount of space, and most users do not need locales. Therefore, it makes more sense to default to purging locales, in order to keep only a few useful ones rather than keeping them all. It helps in providing a small filesystem size by default, and still allows advanced users who really need locales to tune their configuration. As an example, a very basic system with just util-linux enabled (not even Busybox) weights 11 MB, including 6.4 MB of locales. With this new default, the generated system is only 4.2 MB. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-08-02toolchain: libatomic is not built on "uclinux" platformsRomain Naour
The cairo package fails to build on some architectures: BR2_TOOLCHAIN_HAS_LIBATOMIC is enabled, but libatomic is in fact not available. This happens because the gcc logic in libatomic/configure.tgt does not recognize "uclinux" as a valid OS part of the target tuple, and therefore it does not build libatomic. The "uclinux" part of the tuple is used by Buildroot when BR2_BINFMT_FLAT=y, so we make BR2_TOOLCHAIN_HAS_LIBATOMIC enabled only if !BR2_BINFMT_FLAT. It is worth mentioning that support for the uclinux tuple could most likely very easily be added to gcc: it could rely on the generic "posix" implementation of libatomic, which uses pthread locks, available on all architectures where thread support is available. Fixes: [arm] http://autobuild.buildroot.net/results/3d8dc45e41a043d2c2c26bfb26c3617499fbe671 [m68k] http://autobuild.buildroot.net/results/318e01406e3e92eb589ee5b2231c671a4dbb6da4 Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [Thomas: adjust dependency after analysis of the gcc code.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-25toolchain: add 4.7.x choice for headersFabio Estevam
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-24toolchain: add hidden symbol for PIE supportWaldemar Brodkorb
uClibc-ng does not support PIE for some architectures as arc and m68k. It isn't implemented in the static linking case, too. With musl toolchains you might have static PIE support with little patching of gcc. Static linking for GNU libc isn't enabled in buildroot. Fixup any package using special treatment of PIE. (grep -ir pie package/*/*.mk) Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> [Thomas: use positive logic.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03toolchain: add hidden symbol for fortran support in the toolchainSamuel Martin
This symbol should be used in all packages requiring/testing for fortran support. Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-03toolchain/toolchain-common.in: add BR2_TOOLCHAIN_HAS_LIBQUADMATH hidden symbolSamuel Martin
This hidden symbol allow to know when libquadmath can be built and installed. Also, declaring this symbol in toolchain-common.in allows to use it in both external and buildroot toolchain backend. This will be needed for adding/improving the fortran support. Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27m68k: gcc coldfire does not provide _sync atomicsWaldemar Brodkorb
Trying to use __sync_fetch_and_add ends with a gcc ICE. This fixes following autobuild failure, by actually disabling the package for coldfire: http://autobuild.buildroot.net/results/d719db11210d42501332586b4485ab0cc1e125dd/ Signed-off-by: Waldemar Brodkorb <wbx@openadk.org> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-05-16toolchain: add 4.6.x choice for headersGustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-04-27gcc: add support for gcc 6Thomas Petazzoni
This commit adds the support for gcc 6. This release allows to remove a large number of our gcc patches, mainly thanks to the Xtensa and musl related patches being merged upstream. Patches kept with no changes: 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 860-cilk-wchar.patch 890-fix-m68k-compile.patch Patches dropped because they have been merged upstream, or were already upstream backports: 120-gcc-config.gcc-fix-typo-for-powerpc-e6500-cpu_is_64b.patch (merged) 850-libstdcxx-uclibc-c99.patch (merged in a different form, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393) 870-xtensa-add-mauto-litpools-option.patch (upstream backport) 871-xtensa-reimplement-register-spilling.patch (upstream backport) 872-xtensa-use-unwind-dw2-fde-dip-instead-of-unwind-dw2-.patch (upstream backport) 873-xtensa-fix-_Unwind_GetCFA.patch (upstream backport) 874-xtensa-add-uclinux-support.patch (upstream backport) 900-libitm-fixes-for-musl-support.patch (upstream backport) 901-fixincludes-update-for-musl-support.patch (upstream backport) 902-unwind-fix-for-musl.patch (upstream backport) 903-libstdc++-libgfortran-gthr-workaround-for-musl.patch (upstream backport) 904-musl-libc-config.patch (upstream backport) 905-add-musl-support-to-gcc.patch (upstream backport) 905-add-musl-support-to-gcc.patch (upstream backport) 906-mips-musl-support.patch (upstream backport) 907-x86-musl-support.patch (upstream backport) 908-arm-musl-support.patch (upstream backport) 909-aarch64-musl-support.patch (upstream backport) Successfully build-time and run-time tested with qemu_arm_vexpress_defconfig, using gcc 6.x, both in uClibc and musl configurations. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-04-20toolchain-external: CodeSourcery NiosII 2015.11 affected by PR19405Romain Naour
See bug report https://sourceware.org/bugzilla/show_bug.cgi?id=19405 Fixes: http://autobuild.buildroot.net/results/ee562524c5b12191e584ceae89006c5a5103e700 Signed-off-by: Romain Naour <romain.naour@gmail.com> [Thomas: - rename BR2_TOOLCHAIN_BINUTILS_HAS_BUG_19405 to BR2_TOOLCHAIN_HAS_BINUTILS_BUG_19405 - propagate to the qwt package, which is now selecting BR2_PACKAGE_QT_GUI_MODULE.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-04-18arch/x86: remove support for i386Thomas Petazzoni
The Linux kernel doesn't even support i386 anymore, there is no NPTL support for i386 and uClibc-ng only supports NPTL on x86, so there is essentially no usable thread implementation. Most likely glibc and musl also don't support i386 either. So it's time to remove the support for this architecture variant. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-03-20toolchain: introduce BR2_TOOLCHAIN_HAS_LIBATOMICThomas Petazzoni
Until now, we were assuming that whenever you have gcc 4.8, libatomic is available. It turns out that this is not correct, since libatomic will not be available if thread support is disabled in the toolchain. Therefore, __atomic_*() intrinsics may not be available even if the toolchain uses gcc 4.8. To solve this problem, we introduce a BR2_TOOLCHAIN_HAS_LIBATOMIC boolean, which indicates whether the toolchain has libatomic. It is the case when you are using gcc >= 4.8 *and* thread support is enabled. We then use this new BR2_TOOLCHAIN_HAS_LIBATOMIC to define BR2_TOOLCHAIN_HAS_ATOMIC. As explained in the comment, on certain architectures, libatomic is technically not needed to provide the __atomic_*() intrinsics since they might be all built-in. However, since libatomic is only absent in non-thread capable toolchains, it is not worth making things more complex for such seldomly used configuration. Note that we are introducing the intermediate BR2_TOOLCHAIN_HAS_LIBATOMIC option because it will be useful on its own for certain packages. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [Thomas: improve Config.in comment using a suggestion from Yann.]
2016-03-14toolchain: add 4.5.x choice for headersGustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-02-06toolchain: add BR2_TOOLCHAIN_HAS_{SYNC_x, ATOMIC} hidden booleansThomas Petazzoni
Currently, Buildroot provides one BR2_ARCH_HAS_ATOMICS boolean option to indicate whether the architecture supports atomic operations or not. However, the reality of atomic operations support is much more complicated and requires more than one option to be expressed properly. There are in fact two types of atomic built-ins provided by gcc: (1) The __sync_*() family of functions, which have been in gcc for a long time (probably gcc 4.1). They are available in variants operating on 1-byte, 2-byte, 4-byte and 8-byte integers. Some architectures implement a number of variants, some do not implement any, some implement all of them. They are now considered "legacy" by the gcc developers but are nonetheless still being used by a significant number of userspace libraries and applications. https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html (2) The __atomic_*() family of functions, which have been introduced in gcc 4.7. They have been introduced in order to support C++11 atomic operations. In gcc 4.8, they are available on all architectures, either built-in or in the libatomic library part of the gcc runtime (in which case the application needs to be linked with -latomic). In gcc 4.7, the __atomic_*() intrinsics are only supported on certain architectures, since libatomic did not exist at the time. For (1), a single BR2_ARCH_HAS_ATOMICS is not sufficient, because depending on the architecture, some variants may or may not be available. Setting BR2_ARCH_HAS_ATOMICS to false as soon as one of the variant is missing would cause a large number of packages to become unavailable, even if they in fact use only more common variants available on a large number of architectures. For this reason, we've chosen to introduce four new Config.in options: - BR2_TOOLCHAIN_HAS_SYNC_1 - BR2_TOOLCHAIN_HAS_SYNC_2 - BR2_TOOLCHAIN_HAS_SYNC_3 - BR2_TOOLCHAIN_HAS_SYNC_4 Which indicate whether the toolchain support 1-byte, 2-byte, 4-byte and 8-byte __sync_*() built-ins respectively. For (2), we introduce a BR2_TOOLCHAIN_HAS_ATOMIC, which indicates if the __atomic_*() built-ins are available. Note that it is up to the package to link with -latomic when gcc is >= 4.8. Since __atomic_*() intrinsics for all sizes are supported starting We conducted a fairly large analysis about various architectures supported by Buildroot, as well as with a number of different toolchains, to check which combinations support which variant. To do, we linked the following program with various toolchains: int main(void) { uint8_t a; uint16_t b; uint32_t c; uint64_t d; __sync_fetch_and_add(&a, 3); __sync_fetch_and_add(&b, 3); __sync_fetch_and_add(&c, 3); __sync_fetch_and_add(&d, 3); __sync_val_compare_and_swap(&a, 1, 2); __sync_val_compare_and_swap(&b, 1, 2); __sync_val_compare_and_swap(&c, 1, 2); __sync_val_compare_and_swap(&d, 1, 2); __atomic_add_fetch(&a, 3, __ATOMIC_RELAXED); __atomic_add_fetch(&b, 3, __ATOMIC_RELAXED); __atomic_add_fetch(&c, 3, __ATOMIC_RELAXED); __atomic_add_fetch(&d, 3, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&a, &a, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&b, &b, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&c, &c, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); __atomic_compare_exchange_n(&d, &d, 2, 1, __ATOMIC_RELAXED, __ATOMIC_RELAXED); return 0; } And looked at which symbols were unresolved. For the __atomic_*() ones, we tested with and without -latomic to see which variants are built-in, which variants require libatomic. This testing effort has led to the following results: __sync __atomic gcc 1 2 4 8 1 2 4 8 ARC Y Y Y - Y Y Y L 4.8 [with BR2_ARC_ATOMIC_EXT] ARC - - - - L L L L 4.8 [without BR2_ARC_ATOMIC_EXT] ARM Y Y Y X Y Y Y Y 4.8, 4.7 ARM Y Y Y - 4.5 AArch64 Y Y Y Y Y Y Y Y 4.9, 5.1 Bfin - - Y - 4.3 i386 (i386) - - - - L L L L 4.9 i386 (i486..) Y Y Y - L L L L 4.9 [i486, c3, winchip2, winchip-c6] i386 (> i586) Y Y Y Y L L L L 4.9 Microblaze - - Y - L L Y L 4.9 MIPS Y Y Y - Y Y Y L 4.9 MIPS64 Y Y Y Y Y Y Y Y 4.9 NIOS 2 Y Y Y - Y Y Y L 4.9, 5.2 PowerPC Y Y Y - Y Y Y L 4.9 SuperH Y Y Y - Y Y Y L 4.9 SPARC - - - - L L L L 4.9 SPARC64 Y Y Y Y Y Y Y Y 4.9 x86_64 Y Y Y Y Y Y Y Y 4.7, 4.9 Xtensa Y Y Y - Y Y Y Y 4.9 Notes: * __atomic built-ins appeared in gcc 4.7, so for toolchais older than that, the __atomic column is empty. * Y means 'supported built-in' * L means 'supported via linking to libatomic' (only for __atomic functions) * X indicates a very special case for 8 bytes __sync built-ins on ARM. On ARMv7, there is no problem, starting from gcc 4.7, the __sync built-in for 8 bytes integers is implemented, fully in userspace. For cores < ARMv7, doing a 8 bytes atomic operation requires help from the kernel. Unfortunately, the libgcc code implementing this uses the __write() function to display an error, and this function is internal to glibc. Therefore, if you're using glibc everything is fine, but if you're using uClibc or musl, you cannot link an application that uses 8 bytes __sync operations. This has been fixed as part of gcc PR68095, merged in the gcc 5 branch but not yet part of any gcc release. * - means not supported This commit only introduces the new options. Follow-up commits will progressively change the packages using BR2_ARCH_HAS_ATOMICS to use the appropriate BR2_TOOLCHAIN_HAS_SYNC_x or BR2_TOOLCHAIN_HAS_ATOMIC until the point where BR2_ARCH_HAS_ATOMICS can be removed. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-01-30package, toolchain: remove BR2_TOOLCHAIN_HAS_GCC_BUG_* optionsThomas Petazzoni
Quite some time ago, we added the options BR2_TOOLCHAIN_HAS_GCC_BUG_58595 and BR2_TOOLCHAIN_HAS_GCC_BUG_58854 to indicate if the toolchain was affected by those gcc bugs, which were causing build failure with a number of packages. With the recent change in the external toolchain logic to provide only the latest version of each toolchain "family", all the toolchains which were affected by those issues disappeared from Buildroot. Those options are no longer being selected anywhere, and being blind options, it means their value is always going to be "disabled". Conquently, this commit removes those options completely, and updates all the packages where they were used. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-01-11toolchain: add 4.4.x choice for headersGustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-11-02toolchain: add 4.3.x choice for headersVicente Olivert Riera
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Reviewed-by: "James Knight" <james.knight@rockwellcollins.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-09-01toolchain: add 4.2.x choice for headersPeter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2015-08-05toolchain: add common gcc version hidden config optionsThomas Petazzoni
This commit adds a number of hidden Config.in options, that will be used to handle dependencies on the gcc version. We mimic the model that was used for the kernel headers dependency mechanism. These hidden options will be selected by the internal and external toolchain backend logic respectively, in follow-up commits. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
2015-06-22toolchain: add 4.1.x choice for headersGustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-06-09arch: tidy up mmu configGuido Martínez
Instead of blacklisting which architectures support MMUs (mandatorily or optionally), introduce two Kconfig options that are selected by each architecture in each case. This simplifies the logic in BR2_USE_MMU. Signed-off-by: Guido Martínez <guido@vanguardiasur.com.ar> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-22toolchain: drop BR2_INET_IPV6Gustavo Zacarias
It's no longer used so farewell. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-22toolchain: make IPv6 mandatory for external toolchainsGustavo Zacarias
Remove BR2_INET_IPV6 select for predefined external toolchains. Remove the (non)IPv6 option prompt since it's now mandatory. And force the toolchain check now that internal uclibc is always built with IPv6 support and external non-IPv6 toolchains are disallowed. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-13toolchain: add 4.0.x choice for headersGustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-01toolchain-common: drop BR2_LARGEFILEGustavo Zacarias
It's now unused so remove it. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-01toolchain-common: default to Y for LARGEFILEGustavo Zacarias
This will allow us to remove largefile handling in the tree without breaking things while doing so. Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-02-09toolchain: add 3.19 choice for headersPeter Korsgaard
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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-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-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-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-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-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-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-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-01linux-headers: add 3.14, bump 3.{4, 10, 13}.x seriesGustavo Zacarias
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-03-23liburcu: disable build with gcc-4.8.x on ARMSamuel Martin
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>
2014-03-01toolchain/external: check kernel headers version for custom toolchainYann E. MORIN
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>
2014-03-01toolchain/common: add minimum kernel headers optionsYann E. MORIN
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-05 05:26:30 +0000