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) |
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.) > |
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 |
Free forum by Nabble | Edit this page |