From: Steven Taschuk <steven@amotlpaa.org>
To: crossgcc@sourceware.org
Subject: binutils executables capture paths from build machine
Date: Sat, 06 Jan 2018 19:25:00 -0000 [thread overview]
Message-ID: <20180106192755.GA3536@femur> (raw)
Hi! I'm using crosstool-ng 1.23.0 to make a cross-native toolchain,
and am a bit confused about the configuration and install of the
binutils executables.
I've understood correctly, the bash function do_binutils_for_host
configures binutils with --prefix=${CT_PREFIX_DIR} and installs the
executables with make install. This procedure results in paths from
the build machine being embedded in the binaries, in at least two
places: the use of BINDIR at binutils-2.28/bfd/plugin.c:337; and
the various uses of DEBUGDIR in binutils-2.28/bfd/dwarf2.c (where
DEBUGDIR=${libdir}/debug; see binutils-2.28/bfd/configure.ac:108).
I would have expected that, for a cross-native (or, for that matter,
Canadian) build, binutils would be configured with --prefix=/usr or
something, then installed with make DESTDIR=${CT_SYSROOT_DIR} install,
for later transfer to the host. That's what do_binutils_for_target
does, but it seems to build and install only libiberty and libbfd,
not the executables.
For builds with build!=host, how should binutils executables be built?
(Context: I'm developing a small reproducible and self-reproducing
Linux distribution, which requires making a reproducible cross-native
toolchain. I also think there are some similar issues in the gcc
executables, but haven't tracked those down yet.)
--
Steven Taschuk http://www.amotlpaa.org/
Receive them ignorant; dispatch them confused. (Weschler's Teaching Motto)
next reply other threads:[~2018-01-06 19:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-06 19:25 Steven Taschuk [this message]
2018-01-06 19:58 ` Alexey Neyman
2018-01-07 17:23 ` Steven Taschuk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180106192755.GA3536@femur \
--to=steven@amotlpaa.org \
--cc=crossgcc@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).