Re: binutils executables capture paths from build machine

[Alexey Neyman <stilor@att.net>]

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