binutils executables capture paths from build machine

binutils executables capture paths from build machine

[Steven Taschuk]

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)

Re: binutils executables capture paths from build machine

[Alexey Neyman]

On 01/06/2018 11:27 AM, Steven Taschuk wrote:
> 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).

It is not just that. Also, NLS code embeds some build-time paths into 
the code, etc. 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. It may be possible to 
work this around by adding separate --with-foo=PATH options to each an 
every component's configure invocation. But this would be quite time 
consuming and hard to maintain (as the list of such options is likely to 
change from release to release).

So strictly speaking, the toolchain is only guaranteed to work if it is 
later installed at the exact location of CT_PREFIX_DIR. In practice, it 
seems to work fine even if it is relocated (but I haven't tested 
features like LTO with "relocated" toolchain).

For Canadian, the build-to-target cross toolchain is installed in a 
separate location inside a temporary directory; CT_PREFIX_DIR is used as 
the host toolchain (and should, therefore, match the path where the 
toolchain will be placed on the host - but again, in practice it doesn't 
seem to matter much).

Regards,
Alexey.

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

Re: binutils executables capture paths from build machine

[Steven Taschuk]

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