kumquat-buildroot/package/binutils/binutils.mk

143 lines
4.8 KiB
Makefile
Raw Normal View History

################################################################################
#
# binutils
#
################################################################################
# Version is set when using buildroot toolchain.
# If not, we do like other packages
BINUTILS_VERSION = $(call qstrip,$(BR2_BINUTILS_VERSION))
ifeq ($(BINUTILS_VERSION),)
ifeq ($(BR2_arc),y)
BINUTILS_VERSION = arc-2018.03
else
BINUTILS_VERSION = 2.29.1
endif
endif # BINUTILS_VERSION
ifeq ($(BINUTILS_VERSION),arc-2018.03)
BINUTILS_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,binutils-gdb,$(BINUTILS_VERSION))
BINUTILS_SOURCE = binutils-$(BINUTILS_VERSION).tar.gz
BINUTILS_FROM_GIT = y
endif
BINUTILS_SITE ?= $(BR2_GNU_MIRROR)/binutils
BINUTILS_SOURCE ?= binutils-$(BINUTILS_VERSION).tar.xz
BINUTILS_EXTRA_CONFIG_OPTIONS = $(call qstrip,$(BR2_BINUTILS_EXTRA_CONFIG_OPTIONS))
BINUTILS_INSTALL_STAGING = YES
BINUTILS_DEPENDENCIES = $(TARGET_NLS_DEPENDENCIES)
BINUTILS_MAKE_OPTS = LIBS=$(TARGET_NLS_LIBS)
BINUTILS_LICENSE = GPL-3.0+, libiberty LGPL-2.1+
BINUTILS_LICENSE_FILES = COPYING3 COPYING.LIB
ifeq ($(BINUTILS_FROM_GIT),y)
BINUTILS_DEPENDENCIES += host-flex host-bison
HOST_BINUTILS_DEPENDENCIES += host-flex host-bison
endif
binutils, gdb: support unified binutils-gdb git repository If Binutils and/or GDB are fetched from the unified binutils-gdb repository, then the tarball will contain both Binutils and GDB sources, unlike the "normal" tarballs that contain only the titular package. To keep packages separated in Buildroot we need to disable undesired components when configuring. Binutils and GDB migrated to a common Git repository in the October 2013 [1]. Previous Git repositories were incomplete copies of CVS repository which copied only the relevant files (no binutils files in GDB, and vice versa). In the new binutils-gdb repository there is no such separation and a result all files exist in directory after checkout. So if "configure" and "make" are used without explicit targets, all projects will be built: binutils, ld, gas, bfd, opcodes, gdb, etc. In case of Buildroot this would mean that selecting Binutils only, still will build both Binutils and GDB. And if GDB is selected as well, then both packages will be built two times, and Binutils from GDB directory will overwrite initial build of Binutils (or vice versa if Binutils will be built after the GDB). This is a serious problem, because binutils and GDB use separate branches in this common repository. In case of Buildroot this means that separate Git commits (or tags) should be used when downloading source from Git. This affects only Git repositories, because GNU release tarballs still contain only relevant packages. This change is backward compatible, because if "normal" tarball is used (without extra directories), than --disable-* configure options are just ignored by configure. [1] https://sourceware.org/ml/gdb/2013-10/msg00071.html [Thomas: use variables to factorize options, and add comments in the relevant .mk files to explain what's going on.] Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-29 14:54:37 +02:00
# When binutils sources are fetched from the binutils-gdb repository,
# they also contain the gdb sources, but gdb shouldn't be built, so we
# disable it.
BINUTILS_DISABLE_GDB_CONF_OPTS = \
--disable-sim \
--disable-gdb
binutils, gdb: support unified binutils-gdb git repository If Binutils and/or GDB are fetched from the unified binutils-gdb repository, then the tarball will contain both Binutils and GDB sources, unlike the "normal" tarballs that contain only the titular package. To keep packages separated in Buildroot we need to disable undesired components when configuring. Binutils and GDB migrated to a common Git repository in the October 2013 [1]. Previous Git repositories were incomplete copies of CVS repository which copied only the relevant files (no binutils files in GDB, and vice versa). In the new binutils-gdb repository there is no such separation and a result all files exist in directory after checkout. So if "configure" and "make" are used without explicit targets, all projects will be built: binutils, ld, gas, bfd, opcodes, gdb, etc. In case of Buildroot this would mean that selecting Binutils only, still will build both Binutils and GDB. And if GDB is selected as well, then both packages will be built two times, and Binutils from GDB directory will overwrite initial build of Binutils (or vice versa if Binutils will be built after the GDB). This is a serious problem, because binutils and GDB use separate branches in this common repository. In case of Buildroot this means that separate Git commits (or tags) should be used when downloading source from Git. This affects only Git repositories, because GNU release tarballs still contain only relevant packages. This change is backward compatible, because if "normal" tarball is used (without extra directories), than --disable-* configure options are just ignored by configure. [1] https://sourceware.org/ml/gdb/2013-10/msg00071.html [Thomas: use variables to factorize options, and add comments in the relevant .mk files to explain what's going on.] Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com> Cc: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2014-07-29 14:54:37 +02:00
# We need to specify host & target to avoid breaking ARM EABI
BINUTILS_CONF_OPTS = \
--disable-multilib \
--disable-werror \
--host=$(GNU_TARGET_NAME) \
--target=$(GNU_TARGET_NAME) \
--enable-install-libiberty \
--enable-build-warnings=no \
$(BINUTILS_DISABLE_GDB_CONF_OPTS) \
$(BINUTILS_EXTRA_CONFIG_OPTIONS)
ifeq ($(BR2_STATIC_LIBS),y)
BINUTILS_CONF_OPTS += --disable-plugins
endif
# Don't build documentation. It takes up extra space / build time,
# and sometimes needs specific makeinfo versions to work
BINUTILS_CONF_ENV += MAKEINFO=true
BINUTILS_MAKE_OPTS += MAKEINFO=true
BINUTILS_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) MAKEINFO=true install
HOST_BINUTILS_CONF_ENV += MAKEINFO=true
HOST_BINUTILS_MAKE_OPTS += MAKEINFO=true
HOST_BINUTILS_INSTALL_OPTS += MAKEINFO=true install
# Workaround a build issue with -Os for ARM Cortex-M cpus.
# (Binutils 2.25.1 and 2.26.1)
# https://sourceware.org/bugzilla/show_bug.cgi?id=20552
ifeq ($(BR2_ARM_CPU_ARMV7M)$(BR2_OPTIMIZE_S),yy)
BINUTILS_CONF_ENV += CFLAGS="$(TARGET_CFLAGS) -O2"
endif
ifeq ($(BR2_PACKAGE_ZLIB),y)
BINUTILS_DEPENDENCIES += zlib
endif
# "host" binutils should actually be "cross"
# We just keep the convention of "host utility" for now
HOST_BINUTILS_CONF_OPTS = \
--disable-multilib \
--disable-werror \
--target=$(GNU_TARGET_NAME) \
--disable-shared \
--enable-static \
--with-sysroot=$(STAGING_DIR) \
--enable-poison-system-directories \
$(BINUTILS_DISABLE_GDB_CONF_OPTS) \
$(BINUTILS_EXTRA_CONFIG_OPTIONS)
# binutils run configure script of subdirs at make time, so ensure
# our TARGET_CONFIGURE_ARGS are taken into consideration for those
define BINUTILS_BUILD_CMDS
$(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_ARGS) $(MAKE) $(BINUTILS_MAKE_OPTS) -C $(@D)
endef
# We just want libbfd, libiberty and libopcodes,
# not the full-blown binutils in staging
define BINUTILS_INSTALL_STAGING_CMDS
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/bfd DESTDIR=$(STAGING_DIR) install
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/opcodes DESTDIR=$(STAGING_DIR) install
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/libiberty DESTDIR=$(STAGING_DIR) install
endef
# If we don't want full binutils on target
ifneq ($(BR2_PACKAGE_BINUTILS_TARGET),y)
define BINUTILS_INSTALL_TARGET_CMDS
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/bfd DESTDIR=$(TARGET_DIR) install
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/libiberty DESTDIR=$(STAGING_DIR) install
endef
endif
ifneq ($(ARCH_XTENSA_OVERLAY_FILE),)
define BINUTILS_XTENSA_OVERLAY_EXTRACT
$(call arch-xtensa-overlay-extract,$(@D),binutils)
endef
BINUTILS_POST_EXTRACT_HOOKS += BINUTILS_XTENSA_OVERLAY_EXTRACT
BINUTILS_EXTRA_DOWNLOADS += $(ARCH_XTENSA_OVERLAY_URL)
HOST_BINUTILS_POST_EXTRACT_HOOKS += BINUTILS_XTENSA_OVERLAY_EXTRACT
HOST_BINUTILS_EXTRA_DOWNLOADS += $(ARCH_XTENSA_OVERLAY_URL)
endif
toolchain: add link-time-optimization support Add a new option BR2_GCC_ENABLE_LTO that builds gcc and binutils with LTO support. Individual packages still have to enable LTO explicitly by passing '-flto' to GCC, which passes it on to the linker. This option does not add that flag globally. Some packages detect if the compiler supports LTO and enable the flag if it does. To support LTO, ar and ranlib must be called with an argument which triggers the usage of the LTO plugin. Since GCC doesn't call these tools itself, it instead provides wrappers for ar and ranlib that pass the LTO arguments. This way existing Makefiles don't need to be changed for LTO support. However, these wrappers are called <tuple>-gcc-ar which matches the pattern to link to the buildroot wrapper in the external toolchain logic. So the external toolchain logic is updated to provide the correct symlink. [Thomas: - Add a separate BR2_BINUTILS_ENABLE_LTO option to enable LTO support in binutils. This is a blind option, selected by BR2_GCC_ENABLE_LTO. It just avoids having binutils.mk poke directly into gcc Config.in options. - Remove the check on the AVR32 special gcc version, which we don't support anymore. - Adapt the help text of the LTO Config.in option to no longer mention "Since version 4.5", since we only support gcc >= 4.5 in Buildroot anyway. - Fix typo in toolchain-external.mk comment.] Signed-off-by: Peter Kümmel <syntheticpp@gmx.net> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-03-06 13:34:06 +01:00
ifeq ($(BR2_BINUTILS_ENABLE_LTO),y)
HOST_BINUTILS_CONF_OPTS += --enable-plugins --enable-lto
endif
2018-04-22 14:23:50 +02:00
# Hardlinks between binaries in different directories cause a problem
# with rpath fixup, so we de-hardlink those binaries, and replace them
package/binutils: switch from symlinks to copies to fix rpath Commit f9cffb6af464 (binutils: replace hard-links with soft-links to fix rpath) has a side effect that when we build for a noMMU target, elf2flt will in turn replace some of the programs installed by binutils, with its own wrappers. For example, it will rename host/TUPLE/bin/ld to ld.real, and add its own wrapper in place of the original. It does the same for host/bin/TUPLE-ld and host/bin/TUPLE-ld.real. However, we had already made ld a symlink to ../../bin/TUPLE-ld, so host/TUPLE/bin/ld.real will still point to host/bin/TUPLE-ld when we want it to point to ld.real instead... This ultimately confuses gcc later on. Of course, the culprit is also elf2flt, which also installs similar hardlinks that would ultimately exhibit the same rpath issue as the one fixed by f9cffb6af464. Note: we haven't had an issue so far with that, because those tools installed by elf2flt only link with libz, which is most often present on the host system. So, all seem well, but is nonetheless broken; this will be fixed in a subsequent commit. But back on topic. If we were to fix elf2flt with similar symlinks, gcc still gets confused. The underlying reason for this confusion is not entirely clear, though... It looks like something is trying to dereference symlinks and gets confused by the result somehow... So, in an attempt to restore some sanity in all this mess, we try to restore the previous behaviour, we no longer use symlinks but just copy the individual tools. Fixes: #11031. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Christophe Priouzeau <christophe.priouzeau@st.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-05-28 21:45:17 +02:00
# with copies instead.
2018-04-22 14:23:50 +02:00
BINUTILS_TOOLS = ar as ld ld.bfd nm objcopy objdump ranlib readelf strip
define HOST_BINUTILS_FIXUP_HARDLINKS
$(foreach tool,$(BINUTILS_TOOLS),\
package/binutils: switch from symlinks to copies to fix rpath Commit f9cffb6af464 (binutils: replace hard-links with soft-links to fix rpath) has a side effect that when we build for a noMMU target, elf2flt will in turn replace some of the programs installed by binutils, with its own wrappers. For example, it will rename host/TUPLE/bin/ld to ld.real, and add its own wrapper in place of the original. It does the same for host/bin/TUPLE-ld and host/bin/TUPLE-ld.real. However, we had already made ld a symlink to ../../bin/TUPLE-ld, so host/TUPLE/bin/ld.real will still point to host/bin/TUPLE-ld when we want it to point to ld.real instead... This ultimately confuses gcc later on. Of course, the culprit is also elf2flt, which also installs similar hardlinks that would ultimately exhibit the same rpath issue as the one fixed by f9cffb6af464. Note: we haven't had an issue so far with that, because those tools installed by elf2flt only link with libz, which is most often present on the host system. So, all seem well, but is nonetheless broken; this will be fixed in a subsequent commit. But back on topic. If we were to fix elf2flt with similar symlinks, gcc still gets confused. The underlying reason for this confusion is not entirely clear, though... It looks like something is trying to dereference symlinks and gets confused by the result somehow... So, in an attempt to restore some sanity in all this mess, we try to restore the previous behaviour, we no longer use symlinks but just copy the individual tools. Fixes: #11031. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Christophe Priouzeau <christophe.priouzeau@st.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Cc: Peter Korsgaard <peter@korsgaard.com> Cc: Arnout Vandecappelle <arnout@mind.be> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-05-28 21:45:17 +02:00
rm -f $(HOST_DIR)/$(GNU_TARGET_NAME)/bin/$(tool) && \
cp -a $(HOST_DIR)/bin/$(GNU_TARGET_NAME)-$(tool) \
$(HOST_DIR)/$(GNU_TARGET_NAME)/bin/$(tool)
2018-04-22 14:23:50 +02:00
)
endef
HOST_BINUTILS_POST_INSTALL_HOOKS += HOST_BINUTILS_FIXUP_HARDLINKS
$(eval $(autotools-package))
$(eval $(host-autotools-package))