From: Steven Taschuk <steven@amotlpaa.org>
To: crossgcc@sourceware.org
Subject: Re: binutils executables capture paths from build machine
Date: Sun, 07 Jan 2018 17:23:00 -0000 [thread overview]
Message-ID: <20180107172557.GB8958@femur> (raw)
In-Reply-To: <df30423c-03a9-af66-5a64-7fc2f6c7031e@att.net>
Quoth Alexey Neyman:
> On 01/06/2018 11:27 AM, Steven Taschuk wrote:
> > 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).
>
> It is not just that. Also, NLS code embeds some build-time paths
> into the code, etc. [...]
I think in my situation, for binutils, it actually is just these
two spots.
(Details: My config has NLS disabled. To handle debugging
information, I patch the build->host cross toolchain to support
BUILD_PATH_PREFIX_MAP from the Debian reproducible builds project.
I'm not sure what else you had in mind for "etc", but if I tweak
the binutils source in the two places I mentioned to use hard-coded
paths, the binutils executables become reproducible in my build,
in the few environments I've tested. I won't be surprised to find
other irreproducibilities when I expand the set of build environments
that I test with, but that's where things stand right now.)
> [...] The problem is that we don't know where the
> toolchain will be located and many configure scripts "automagically"
> find headers/libraries based on the value of $prefix. [...]
Yeah, I understand that many packages are distributed with build
systems that don't support the build!=host case well, and that
magical autodetection in configure scripts is a big part of that, and
I certainly don't expect crosstool-ng to fix everybody else's build
systems. As you said, that'd be a huge ongoing maintenance headache.
Is this known to be a problem with binutils specifically?
Also, if it is a problem with binutils, why does do_binutils_for_target
use the procedure where --prefix refers to a path on the host, and
DESTDIR is used to install it elsewhere on the build machine?
--
Steven Taschuk http://www.amotlpaa.org/
"What? shall we receive good at the hand of God,
and shall we not receive evil?" -- Job 2:10
prev parent reply other threads:[~2018-01-07 17:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-06 19:25 Steven Taschuk
2018-01-06 19:58 ` Alexey Neyman
2018-01-07 17:23 ` Steven Taschuk [this message]
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=20180107172557.GB8958@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).