2013-06-06 01:53:30 +02:00
|
|
|
################################################################################
|
2010-12-31 12:39:01 +01:00
|
|
|
#
|
|
|
|
|
# binutils
|
|
|
|
|
#
|
2013-06-06 01:53:30 +02:00
|
|
|
################################################################################
|
2010-12-31 12:39:01 +01:00
|
|
|
|
2011-06-08 15:57:26 +02:00
|
|
|
# Version is set when using buildroot toolchain.
|
|
|
|
|
# If not, we do like other packages
|
2010-12-31 12:39:01 +01:00
|
|
|
BINUTILS_VERSION = $(call qstrip,$(BR2_BINUTILS_VERSION))
|
2011-06-08 15:57:26 +02:00
|
|
|
ifeq ($(BINUTILS_VERSION),)
|
2015-03-15 16:56:00 +01:00
|
|
|
ifeq ($(BR2_arc),y)
|
2020-11-02 15:50:54 +01:00
|
|
|
BINUTILS_VERSION = arc-2020.09-release
|
2015-03-15 16:56:00 +01:00
|
|
|
else
|
2021-01-31 23:33:01 +01:00
|
|
|
BINUTILS_VERSION = 2.35.2
|
2011-06-08 15:57:26 +02:00
|
|
|
endif
|
2015-03-15 16:56:00 +01:00
|
|
|
endif # BINUTILS_VERSION
|
2011-06-08 15:57:26 +02:00
|
|
|
|
2020-11-02 15:50:54 +01:00
|
|
|
ifeq ($(BINUTILS_VERSION),arc-2020.09-release)
|
2014-08-21 19:33:56 +02:00
|
|
|
BINUTILS_SITE = $(call github,foss-for-synopsys-dwc-arc-processors,binutils-gdb,$(BINUTILS_VERSION))
|
2018-12-06 15:17:33 +01:00
|
|
|
BINUTILS_SOURCE = binutils-gdb-$(BINUTILS_VERSION).tar.gz
|
2013-12-05 18:20:58 +01:00
|
|
|
BINUTILS_FROM_GIT = y
|
2013-12-05 18:20:52 +01:00
|
|
|
endif
|
2019-05-31 08:39:03 +02:00
|
|
|
|
|
|
|
|
ifeq ($(BR2_csky),y)
|
|
|
|
|
BINUTILS_SITE = $(call github,c-sky,binutils-gdb,$(BINUTILS_VERSION))
|
|
|
|
|
BINUTILS_SOURCE = binutils-$(BINUTILS_VERSION).tar.gz
|
|
|
|
|
BINUTILS_FROM_GIT = y
|
|
|
|
|
endif
|
|
|
|
|
|
2013-12-05 18:20:48 +01:00
|
|
|
BINUTILS_SITE ?= $(BR2_GNU_MIRROR)/binutils
|
2017-07-29 15:09:03 +02:00
|
|
|
BINUTILS_SOURCE ?= binutils-$(BINUTILS_VERSION).tar.xz
|
2010-12-31 12:39:01 +01:00
|
|
|
BINUTILS_EXTRA_CONFIG_OPTIONS = $(call qstrip,$(BR2_BINUTILS_EXTRA_CONFIG_OPTIONS))
|
|
|
|
|
BINUTILS_INSTALL_STAGING = YES
|
2017-07-03 22:40:02 +02:00
|
|
|
BINUTILS_DEPENDENCIES = $(TARGET_NLS_DEPENDENCIES)
|
|
|
|
|
BINUTILS_MAKE_OPTS = LIBS=$(TARGET_NLS_LIBS)
|
2017-03-30 15:43:34 +02:00
|
|
|
BINUTILS_LICENSE = GPL-3.0+, libiberty LGPL-2.1+
|
2012-11-13 02:05:38 +01:00
|
|
|
BINUTILS_LICENSE_FILES = COPYING3 COPYING.LIB
|
2021-01-11 23:43:29 +01:00
|
|
|
BINUTILS_CPE_ID_VENDOR = gnu
|
2010-12-31 12:39:01 +01:00
|
|
|
|
2013-12-05 18:20:58 +01:00
|
|
|
ifeq ($(BINUTILS_FROM_GIT),y)
|
2016-10-11 14:02:33 +02:00
|
|
|
BINUTILS_DEPENDENCIES += host-flex host-bison
|
|
|
|
|
HOST_BINUTILS_DEPENDENCIES += host-flex host-bison
|
2016-07-05 11:46:59 +02:00
|
|
|
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.
|
2014-09-27 21:32:44 +02:00
|
|
|
BINUTILS_DISABLE_GDB_CONF_OPTS = \
|
2014-12-24 08:54:24 +01:00
|
|
|
--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
|
|
|
|
2010-12-31 12:39:01 +01:00
|
|
|
# We need to specify host & target to avoid breaking ARM EABI
|
2014-12-24 08:54:24 +01:00
|
|
|
BINUTILS_CONF_OPTS = \
|
|
|
|
|
--disable-multilib \
|
|
|
|
|
--disable-werror \
|
|
|
|
|
--host=$(GNU_TARGET_NAME) \
|
|
|
|
|
--target=$(GNU_TARGET_NAME) \
|
|
|
|
|
--enable-install-libiberty \
|
2016-08-19 18:29:21 +02:00
|
|
|
--enable-build-warnings=no \
|
2014-12-24 08:54:24 +01:00
|
|
|
$(BINUTILS_DISABLE_GDB_CONF_OPTS) \
|
|
|
|
|
$(BINUTILS_EXTRA_CONFIG_OPTIONS)
|
2010-12-31 12:39:01 +01:00
|
|
|
|
2016-03-19 21:14:56 +01:00
|
|
|
ifeq ($(BR2_STATIC_LIBS),y)
|
|
|
|
|
BINUTILS_CONF_OPTS += --disable-plugins
|
|
|
|
|
endif
|
|
|
|
|
|
2014-06-30 19:02:37 +02:00
|
|
|
# Don't build documentation. It takes up extra space / build time,
|
|
|
|
|
# and sometimes needs specific makeinfo versions to work
|
2016-10-11 14:02:33 +02:00
|
|
|
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
|
2014-06-30 19:02:37 +02:00
|
|
|
|
2016-09-04 16:14:00 +02:00
|
|
|
# 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
|
|
|
|
|
|
2016-02-21 19:09:12 +01:00
|
|
|
ifeq ($(BR2_PACKAGE_ZLIB),y)
|
|
|
|
|
BINUTILS_DEPENDENCIES += zlib
|
|
|
|
|
endif
|
|
|
|
|
|
2010-12-31 12:39:01 +01:00
|
|
|
# "host" binutils should actually be "cross"
|
|
|
|
|
# We just keep the convention of "host utility" for now
|
2014-12-24 08:54:24 +01:00
|
|
|
HOST_BINUTILS_CONF_OPTS = \
|
|
|
|
|
--disable-multilib \
|
|
|
|
|
--disable-werror \
|
|
|
|
|
--target=$(GNU_TARGET_NAME) \
|
|
|
|
|
--disable-shared \
|
|
|
|
|
--enable-static \
|
|
|
|
|
--with-sysroot=$(STAGING_DIR) \
|
|
|
|
|
--enable-poison-system-directories \
|
package/binutils: build host binutils w/o debuginfod
Since version 2.34 binutils enables debuginfod support by default if the
debuginfod library is found to be available at build time.
On Fedora 32, libdebuginfod may be present on the system, and the
dependency chain of interest is then:
libdebuginfod.so
-> libcurl.so
-> libk5crypto.so
-> libcrypto.so
If the Buildroot configuration ever needs to build host-openssl, which
may happen when building the kernel to sign modules for example, this
leads to an inconsistency between the system-provided libcrypto and
ours, leading to missing symbols:
$ make defconfig
$ make host-binutils
$ ./output/host/bin/i686-buildroot-linux-uclibc-objdump --help
[--snip some help text--]
$ make host-openssl
$ ./output/host/bin/i686-buildroot-linux-uclibc-objdump --help
./output/host/bin/i686-buildroot-linux-uclibc-objdump: symbol lookup
error: /lib64/libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version
OPENSSL_1_1_1b
EVP_KDF_ctrl comes from libcrypto:
$ nm -D /usr/lib64/libcrypto.so.1.1 |grep EVP_KDF_ctrl
0000000000176000 T EVP_KDF_ctrl
$ nm -D output/host/lib/libcrypto.so.1.1 |grep EVP_KDF_ctrl
[--empty--]
So, if host-binutils tools, like objdump et al., are called after our
host-openssl is built, then when run, the system-provided libk5crypto.so
is used, but our libcrypto.so is used, because of the RPATH we set on
our host tools.
And boom.
Note that there is also a latent similar issue if we were to build our
host-libcurl too...
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
[yann.morin.1998@free.fr: rewrite commit log with a bit more info]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2020-10-19 19:05:33 +02:00
|
|
|
--without-debuginfod \
|
2014-12-24 08:54:24 +01:00
|
|
|
$(BINUTILS_DISABLE_GDB_CONF_OPTS) \
|
|
|
|
|
$(BINUTILS_EXTRA_CONFIG_OPTIONS)
|
2010-12-31 12:39:01 +01:00
|
|
|
|
2016-02-01 23:42:35 +01:00
|
|
|
# binutils run configure script of subdirs at make time, so ensure
|
|
|
|
|
# our TARGET_CONFIGURE_ARGS are taken into consideration for those
|
2019-04-27 18:06:14 +02:00
|
|
|
BINUTILS_MAKE_ENV = $(TARGET_CONFIGURE_ARGS)
|
2016-02-01 23:42:35 +01:00
|
|
|
|
2014-08-06 01:00:09 +02:00
|
|
|
# We just want libbfd, libiberty and libopcodes,
|
|
|
|
|
# not the full-blown binutils in staging
|
2010-12-31 12:39:01 +01:00
|
|
|
define BINUTILS_INSTALL_STAGING_CMDS
|
2016-10-17 18:06:43 +02:00
|
|
|
$(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
|
2010-12-31 12:39:01 +01:00
|
|
|
endef
|
|
|
|
|
|
2011-06-08 15:57:26 +02:00
|
|
|
# If we don't want full binutils on target
|
|
|
|
|
ifneq ($(BR2_PACKAGE_BINUTILS_TARGET),y)
|
2010-12-31 12:39:01 +01:00
|
|
|
define BINUTILS_INSTALL_TARGET_CMDS
|
2011-06-08 15:57:26 +02:00
|
|
|
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/bfd DESTDIR=$(TARGET_DIR) install
|
2020-05-13 19:02:33 +02:00
|
|
|
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/opcodes DESTDIR=$(TARGET_DIR) install
|
2016-10-17 18:06:43 +02:00
|
|
|
$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/libiberty DESTDIR=$(STAGING_DIR) install
|
2010-12-31 12:39:01 +01:00
|
|
|
endef
|
2011-06-08 15:57:26 +02:00
|
|
|
endif
|
2010-12-31 12:39:01 +01:00
|
|
|
|
arch/xtensa: allow specifying path to tarball file
currently, specifying a custom Xtrensa core is done with two variables:
- the core name
- the directory containing the overlay tarball
However, the core name only serves to construct the tarball name, and is
not used whatsoever to configure any of the toolchain components
(binutils, gcc or gdb), except through the files that are overlayed in
their respective source trees.
This has two main drawbacks:
- the overlay file must be named after the core,
- the tarball can not be compressed.
Furthermore, it also makes it extremely complex to implement a download
of that tarball.
So, those two variables can be squeezed into a single variable, that is
the complete path of the overlay tarball.
Update the qemu-xtensa defconfig accordingly.
Note: we do not add a legacy entry for BR2_XTENSA_CORE_NAME, since it
was previously a blind option in the last release, and there's been no
release since we removed BR2_XTENSA_CUSTOM_NAME. So, we just update the
legacy comments for BR2_XTENSA_CUSTOM_NAME, since that's all the user
could have seen in any of our releases so far.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-07-09 14:21:56 +02:00
|
|
|
ifneq ($(ARCH_XTENSA_OVERLAY_FILE),)
|
2017-03-14 19:30:39 +01:00
|
|
|
define BINUTILS_XTENSA_OVERLAY_EXTRACT
|
2017-03-14 19:30:36 +01:00
|
|
|
$(call arch-xtensa-overlay-extract,$(@D),binutils)
|
2012-11-15 04:53:52 +01:00
|
|
|
endef
|
2017-03-14 19:30:39 +01:00
|
|
|
BINUTILS_POST_EXTRACT_HOOKS += BINUTILS_XTENSA_OVERLAY_EXTRACT
|
2017-07-09 14:21:58 +02:00
|
|
|
BINUTILS_EXTRA_DOWNLOADS += $(ARCH_XTENSA_OVERLAY_URL)
|
2017-03-14 19:30:39 +01:00
|
|
|
HOST_BINUTILS_POST_EXTRACT_HOOKS += BINUTILS_XTENSA_OVERLAY_EXTRACT
|
2017-07-09 14:21:58 +02:00
|
|
|
HOST_BINUTILS_EXTRA_DOWNLOADS += $(ARCH_XTENSA_OVERLAY_URL)
|
2012-11-15 04:53:52 +01:00
|
|
|
endif
|
|
|
|
|
|
2015-03-06 13:34:06 +01:00
|
|
|
ifeq ($(BR2_BINUTILS_ENABLE_LTO),y)
|
|
|
|
|
HOST_BINUTILS_CONF_OPTS += --enable-plugins --enable-lto
|
|
|
|
|
endif
|
|
|
|
|
|
binutils: replace hard-links with soft-links to fix rpath
binutils installs its binaries both as bin/<tuple>-<tool> and as
<tuple>/bin/<tool>, and hardlinks are used to reduce disk space
consumption. This causes a problem for host-binutils with our rpath
fixing logic done by "make sdk".
Indeed, the fix-rpath script starts by fixing up the rpath of
bin/<tuple>-<tool>, and sets the RPATH to $ORIGIN/../lib/. Then
fix-rpath moves on to <tuple>/bin/<tool>, and doesn't find the library
the tool depends on, and clears the RPATH. The result is that the
binutils tool are not usable.
Note that this is only visible currently on the ARC architecture,
because on this architecture, binutils is fetched from git, which
causes host-flex to be built, and some binutils tools to use the libfl
shared library. Therefore, the binutils tools don't use just the
standard C library (which is provided by the system) but also libfl
from $(HOST_DIR)/lib, and therefore if the RPATH isn't set correctly,
those tools don't work properly.
In order to address this, this comit adds a post-install hook to
host-binutils that replaces those hard links by symbolic links. It is
worth mentioning that library loading and RPATH usage occurs *after*
resolving the symbolic links, which makes this solution work.
Fixes:
http://autobuild.buildroot.net/results/b2562b05d397d4e1ffe0f8d2f4ce4c84ab6feae1/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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.
|
binutils: replace hard-links with soft-links to fix rpath
binutils installs its binaries both as bin/<tuple>-<tool> and as
<tuple>/bin/<tool>, and hardlinks are used to reduce disk space
consumption. This causes a problem for host-binutils with our rpath
fixing logic done by "make sdk".
Indeed, the fix-rpath script starts by fixing up the rpath of
bin/<tuple>-<tool>, and sets the RPATH to $ORIGIN/../lib/. Then
fix-rpath moves on to <tuple>/bin/<tool>, and doesn't find the library
the tool depends on, and clears the RPATH. The result is that the
binutils tool are not usable.
Note that this is only visible currently on the ARC architecture,
because on this architecture, binutils is fetched from git, which
causes host-flex to be built, and some binutils tools to use the libfl
shared library. Therefore, the binutils tools don't use just the
standard C library (which is provided by the system) but also libfl
from $(HOST_DIR)/lib, and therefore if the RPATH isn't set correctly,
those tools don't work properly.
In order to address this, this comit adds a post-install hook to
host-binutils that replaces those hard links by symbolic links. It is
worth mentioning that library loading and RPATH usage occurs *after*
resolving the symbolic links, which makes this solution work.
Fixes:
http://autobuild.buildroot.net/results/b2562b05d397d4e1ffe0f8d2f4ce4c84ab6feae1/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
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)
|
binutils: replace hard-links with soft-links to fix rpath
binutils installs its binaries both as bin/<tuple>-<tool> and as
<tuple>/bin/<tool>, and hardlinks are used to reduce disk space
consumption. This causes a problem for host-binutils with our rpath
fixing logic done by "make sdk".
Indeed, the fix-rpath script starts by fixing up the rpath of
bin/<tuple>-<tool>, and sets the RPATH to $ORIGIN/../lib/. Then
fix-rpath moves on to <tuple>/bin/<tool>, and doesn't find the library
the tool depends on, and clears the RPATH. The result is that the
binutils tool are not usable.
Note that this is only visible currently on the ARC architecture,
because on this architecture, binutils is fetched from git, which
causes host-flex to be built, and some binutils tools to use the libfl
shared library. Therefore, the binutils tools don't use just the
standard C library (which is provided by the system) but also libfl
from $(HOST_DIR)/lib, and therefore if the RPATH isn't set correctly,
those tools don't work properly.
In order to address this, this comit adds a post-install hook to
host-binutils that replaces those hard links by symbolic links. It is
worth mentioning that library loading and RPATH usage occurs *after*
resolving the symbolic links, which makes this solution work.
Fixes:
http://autobuild.buildroot.net/results/b2562b05d397d4e1ffe0f8d2f4ce4c84ab6feae1/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-04-22 14:23:50 +02:00
|
|
|
)
|
|
|
|
|
endef
|
|
|
|
|
HOST_BINUTILS_POST_INSTALL_HOOKS += HOST_BINUTILS_FIXUP_HARDLINKS
|
|
|
|
|
|
2012-07-03 00:07:32 +02:00
|
|
|
$(eval $(autotools-package))
|
2012-07-03 00:06:54 +02:00
|
|
|
$(eval $(host-autotools-package))
|
