buildroot/package/binutils/Config.in, branch 2016.08

binutils: enable as target package for aarch64

2016-06-08T21:55:05+00:00

binutils got disabled as a target package for aarch64 back in Buildroot 2012.11 (commit 660d16f4). The default version 2.21.1 at the time didn't really support aarch64, as shown by the autobuilder error reference in that commit. binutils has now had support for aarch64 since 2.23, but was never re-enabled for aarch64. All of the binutils versions currently supported by Buildroot (oldest being 2.24) support aarch64, so we can now enable it without any restrictions. This same patch also touches the dropwatch, lightning and oprofile packages which all select binutils and had the 'depends on !aarch64' to keep Kconfig consistent. They are now re-enabled for aarch64 as well. They are changed in this same patch so that Kconfig is kept consistent and doesn't end up having them disabled in a commit which only has the binutils change applied. lightning has other explicit arch dependencies so it is not actually yet available in aarch64, but at least the dependency on !aarch64 because of binutils is not needed anymore. Everything has been build tested with Buildroot and external toolchains. binutils and dropwatch work fine in a qemu target. oprofile doesn't seem to be supported in the qemu aarch64 processor but builds fine and seems to have some level of aarch64 support in the source, so there doesn't seem to be a reason to keep it disabled in Kconfig. Signed-off-by: Erico Nunes Signed-off-by: Thomas Petazzoni

package/binutils: fix comment dependencies

2014-12-07T21:05:26+00:00

[Thomas: re-adjust dependencies, according to Yann's comment.] Signed-off-by: Romain Naour Signed-off-by: Thomas Petazzoni

binutils: now depends on wchar

2014-10-29T21:13:13+00:00

binutils starting at least from 2.23 when build for target require uClibc configured with UCLIBC_HAS_WCHAR otherwise: libtool: link: [...] -o as-new [...] read.o: In function `read_symbol_name': read.c:(.text+0x3634): undefined reference to `mbstowcs' collect2: error: ld returned 1 exit status because "mbstowcs" is not available in the C library. Even though we're not yet using 2.23.2 as the default version, we will probably do it in the near future, so this commit doesn't bother with making the wchar dependency version-specific, and applies it to the binutils package as a whole. Fixes bug #6218 [Thomas: - more details in the commit log. - add comment about the wchar dependency - propagate the dependency to dropwatch (and fix a mistake in the architecture dependencies of the comment) - propagate the dependency to oprofile.] Signed-off-by: Alexey Brodkin Cc: Anton Kolesov Cc: Thomas Petazzoni Signed-off-by: Thomas Petazzoni Reviewed-by: Arnout Vandecappelle (Essensium/Mind)

binutils: do not allow on NIOS2, no support available

2013-12-25T11:31:18+00:00

binutils does not have support for NIOS2 on the target, so disable the selection of binutils on this architecture. Fixes: http://autobuild.buildroot.org/results/40d/40d9cbefd03727af82610412ed0bc47674c44dbb/build-end.log Signed-off-by: Thomas Petazzoni Acked-by: Ezequiel Garcia

Config.in files: use if/endif instead of 'depends on' for main symbol

2013-12-25T11:21:39+00:00

In the Config.in file of package foo, it often happens that there are other symbols besides BR2_PACKAGE_FOO. Typically, these symbols only make sense when foo itself is enabled. There are two ways to express this: with depends on BR2_PACKAGE_FOO in each extra symbol, or with if BR2_PACKAGE_FOO ... endif around the entire set of extra symbols. The if/endif approach avoids the repetition of 'depends on' statements on multiple symbols, so this is clearly preferred. But even when there is only one extra symbol, if/endif is a more logical choice: - it is future-proof for when extra symbols are added - it allows to have just one strategy instead of two (less confusion) This patch modifies the Config.in files accordingly. Signed-off-by: Thomas De Schampheleire Signed-off-by: Thomas Petazzoni

binutils: not available for the target on AArch64

2012-11-28T19:35:43+00:00

Fixes: http://autobuild.buildroot.org/results/74082860f607cbd857654e9504f5f7e7ae47c0ac/build-end.log Signed-off-by: Thomas Petazzoni Signed-off-by: Peter Korsgaard

Remove all references to libintl

2012-09-20T19:33:38+00:00

From now on, packages only need to select the BR2_PACKAGE_GETTEXT option and depend on the 'gettext' package to get the necessary i18n libraries installed on the target. Signed-off-by: Thomas Petazzoni Tested-by: "Yann E. MORIN" [yann.morin.1998@free.fr: remove BR2_PACKAGE_LIBINTL] Signed-off-by: "Yann E. MORIN" Tested-by: Arnout Vandecappelle (Essensium/Mind) Acked-by: Arnout Vandecappelle (Essensium/Mind) CC: Samuel Martin Signed-off-by: Peter Korsgaard

binutils: Makefile and Config.in rework for oprofile ext toolchain compilation

2011-10-27T12:04:56+00:00

* When select full binutils binaries use the default INSTALL_TARGET_CMDS from AUTOTARGET. * Menu config improvement. * Install libiberty into Staging dir. [Peter: Fix typos, Config.in fixes, install libiberty to target as well] Signed-off-by: Benoit Mauduit Signed-off-by: Peter Korsgaard

binutils: make it a proper package

2011-01-02T21:55:16+00:00

* Convert binutils to a proper autotargets package * Add version 2.21 and drop version 2.17 * Hook up packaged binutils for target gcc * Build tools are on HOST_DIR now so change it * Move cross/host gcc to HOST_DIR * Drop kludge from commit 3c77bab2eeace3ee675bd745ca335fa3dd1630bb This is fixed in the next commit "gcc: install copies of libgcc, libstdc++ and libgcj to the sysroot" - tested for arm & x86_64 targets. * TARGET_CROSS now pointed to HOST_DIR too [Peter: Config.in tweaks] Signed-off-by: Gustavo Zacarias Signed-off-by: Peter Korsgaard