public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
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

      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).