Consider cross-compiling binutils for a sysroot, then install it into the sysroot (with DESTDIR) and move the sysroot onto the target machine.  Then we should be able to build packages on the target machine with binutils (and GCC, but it's another topic) just built.

However, we hit a problem when the target machine and the build machine *happen* to be compatible.  We configure binutils like this:

../configure                   \
    --prefix=/usr              \
    --build=$(../config.guess) \
    --host=$TARGET_TRIPLE      \
    --disable-nls              \
    --enable-shared            \
    --disable-werror

Then binutils build fine (with $TARGET_TRIPLE-gcc and $TARGET_TRIPLE-ld etc, all configured with sysroot). Then we want to use DESTDIR to install binutils into the sysroot, like:

    make install DESTDIR=/mnt/build_dir/sources/sysroot

libctf.la is then relinked with:

libtool: install: warning: relinking `libctf.la'
libtool: install: (cd /mnt/build_dir/sources/binutils-2.38/build/libctf; /bin/sh /mnt/build_dir/sources/binutils-2.38/build/libctf/libtool  --silent --tag CC --mode=relink x86_64-lfs-linux-gnu-gcc -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long -I../../libctf/../zlib -g -O2 -version-info 0:0:0 -Wl,--version-script=../../libctf/libctf.ver -o libctf.la -rpath /usr/lib libctf_la-ctf-archive.lo libctf_la-ctf-dump.lo libctf_la-ctf-create.lo libctf_la-ctf-decl.lo libctf_la-ctf-error.lo libctf_la-ctf-hash.lo libctf_la-ctf-labels.lo libctf_la-ctf-dedup.lo libctf_la-ctf-link.lo libctf_la-ctf-lookup.lo libctf_la-ctf-open.lo libctf_la-ctf-serialize.lo libctf_la-ctf-sha1.lo libctf_la-ctf-string.lo libctf_la-ctf-subr.lo libctf_la-ctf-types.lo libctf_la-ctf-util.lo libctf_la-ctf-open-bfd.lo -L/mnt/build_dir/sources/binutils-2.38/build/libctf/../libiberty/pic -liberty ../bfd/libbfd.la -L/mnt/build_dir/sources/binutils-2.38/build/libctf/../libiberty/pic -liberty -L./../zlib -lz -inst-prefix-dir /mnt/build_dir/sources/sysroot)

It seems OK, but "../bfd/libbfd.la" contains:

    libdir='/usr/lib'

At ltmain.sh:6003:

    # We cannot seem to hardcode it, guess we'll fake it.
    add_dir="-L$libdir"

This effectively add "-L/usr/lib" into the $TARGET_TRIPLE-gcc command line.  The command line is now like:

$TARGET_TRIPLE-gcc -shared  -fPIC -DPIC  .libs/libctf_la-ctf-archive.o ... ... -L/mnt/build_dir/sources/binutils-2.38/build/libctf/../libiberty/pic -L/mnt/build_dir/sources/sysroot/usr/lib -L/usr/lib -lbfd -L/mnt/build_dir/sources/binutils-2.38/build/bfd/../libiberty/pic -L/mnt/build_dir/sources/binutils-2.38/build/zlib -liberty -lz  -Wl,--version-script=../../libctf/libctf.ver   -Wl,-soname -Wl,libctf.so.0 -o .libs/libctf.so.0.0.0

"-L/usr/lib ... -lz" causes system zlib (/usr/lib/libz.so) to be used, instead of our shipped zlib (/mnt/build_dir/sources/binutils-2.38/build/zlib/libz.a).  But libz.so does not exist in the sysroot, so we can't use binutils after moving the sysroot onto the target machine.

Maybe the "Component" shouldn't be libctf: libopcodes suffers the same issue.  But there is not a "building system" component in bugzilla...