NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
a4e713bf34
kumquat-buildroot/package/binutils/Config.in

26 lines
496 B
Plaintext
Raw Normal View History

binutils: make it a proper package * 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 <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-31 12:39:01 +01:00
config BR2_PACKAGE_BINUTILS
binutils: Makefile and Config.in rework for oprofile ext toolchain compilation * 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 <benoit.mauduit@openwide.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-06-08 15:57:26 +02:00
bool "binutils"
binutils: enable as target package for aarch64 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 <nunes.erico@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-29 05:33:35 +02:00
depends on !BR2_nios2
binutils: now depends on wchar 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 <abrodkin@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2014-10-28 23:19:18 +01:00
depends on BR2_USE_WCHAR
binutils: make it a proper package * 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 <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-31 12:39:01 +01:00
help
binutils: Makefile and Config.in rework for oprofile ext toolchain compilation * 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 <benoit.mauduit@openwide.fr> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2011-06-08 15:57:26 +02:00
Install binutils on the target
binutils: make it a proper package * 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 <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-31 12:39:01 +01:00
Config.in files: use if/endif instead of 'depends on' for main symbol 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 <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-12-20 22:31:30 +01:00
if BR2_PACKAGE_BINUTILS
binutils: make it a proper package * 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 <gustavo@zacarias.com.ar> Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
2010-12-31 12:39:01 +01:00
config BR2_PACKAGE_BINUTILS_TARGET
bool "binutils binaries"
help
The GNU Binutils are a collection of binary tools:
ld - the GNU linker.
as - the GNU assembler.
and others...
http://www.gnu.org/software/binutils/
Config.in files: use if/endif instead of 'depends on' for main symbol 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 <thomas.de.schampheleire@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2013-12-20 22:31:30 +01:00
endif
binutils: now depends on wchar 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 <abrodkin@synopsys.com> Cc: Anton Kolesov <akolesov@synopsys.com> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2014-10-28 23:19:18 +01:00
comment "binutils needs a toolchain w/ wchar"
binutils: enable as target package for aarch64 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 <nunes.erico@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-05-29 05:33:35 +02:00
depends on !BR2_nios2
package/binutils: fix comment dependencies [Thomas: re-adjust dependencies, according to Yann's comment.] Signed-off-by: Romain Naour <romain.naour@openwide.fr> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-12-04 22:11:02 +01:00
depends on !BR2_USE_WCHAR
Reference in New Issue Copy Permalink