Seeing a similar thing in binutils 2.36.1, which includes the patch that Rolf points to on Source Mage Gnu Linux.

A relink of libctf.la is triggered during make install which fails as we have already removed binutils binaries in preparation for that installation as can be seen below. The last two lines are from sorcery, our package management software.

make[3]: Entering directory '/usr/src/binutils-2.36.1/buildit/libctf'
 /bin/mkdir -p '/usr/lib'
 /bin/sh ./libtool   --mode=install /bin/install -c   libctf.la libctf-nobfd.la '/usr/lib'
libtool: install: warning: relinking `libctf.la'
libtool: install: (cd /usr/src/binutils-2.36.1/buildit/libctf; /bin/sh /usr/src/binutils-2.36.1/buildit/libctf/libtool  --tag CC --mode=relink i686-pc-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 -march=i686 -pipe -version-info 0:0:0 -Wl,--version-script=../../libctf/libctf.ver -s -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-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 ../bfd/libbfd.la -L/usr/src/binutils-2.36.1/buildit/libctf/../libiberty/pic -liberty -lz -ldl )
libtool: relink: i686-pc-linux-gnu-gcc -shared  -fPIC -DPIC  .libs/libctf_la-ctf-archive.o .libs/libctf_la-ctf-dump.o .libs/libctf_la-ctf-create.o .libs/libctf_la-ctf-decl.o .libs/libctf_la-ctf-error.o .libs/libctf_la-ctf-hash.o .libs/libctf_la-ctf-labels.o .libs/libctf_la-ctf-dedup.o .libs/libctf_la-ctf-link.o .libs/libctf_la-ctf-lookup.o .libs/libctf_la-ctf-open.o .libs/libctf_la-ctf-sha1.o .libs/libctf_la-ctf-string.o .libs/libctf_la-ctf-subr.o .libs/libctf_la-ctf-types.o .libs/libctf_la-ctf-util.o .libs/libctf_la-ctf-open-bfd.o   -L/usr/lib -lbfd -L/usr/src/binutils-2.36.1/buildit/bfd/../libiberty/pic -L/usr/src/binutils-2.36.1/buildit/libctf/../libiberty/pic -liberty -lz -ldl  -march=i686 -Wl,--version-script=../../libctf/libctf.ver   -Wl,-soname -Wl,libctf.so.0 -o .libs/libctf.so.0.0.0
collect2: fatal error: cannot find 'ld'
compilation terminated.
libtool: install: error: relink `libctf.la' with the above command before installing it
make[3]: *** [Makefile:552: install-libLTLIBRARIES] Error 1
make[3]: Leaving directory '/usr/src/binutils-2.36.1/buildit/libctf'
make[2]: *** [Makefile:1206: install-am] Error 2
make[2]: Leaving directory '/usr/src/binutils-2.36.1/buildit/libctf'
make[1]: *** [Makefile:10515: install-libctf] Error 2
make[1]: Leaving directory '/usr/src/binutils-2.36.1/buildit'
make: *** [Makefile:2289: install] Error 2
 Problem Detected! 
INSTALL failed!

Why is libctf.la being relinked during install phase? The build phase should have created a proper version of that file, no?

Funnily enough on 2.36 everything seems to be fine, so apparently this relink did not happen during install phase and I presume build phase provided it correctly.

This is probably a duplicate of bug 27360. Could you try the users/nalcock/libctf-install-relink branch and see if that fixes it?

(libtool has to relink libctf during installation because during installation it is linked with explicit RPATHs which point into the build tree, so that you can run programs that link to it directly without installing its dependencies, as the libctf testsuite does. OF course, that RPATH has to be stripped out at install time without pulling in a libbfd from /usr/local/lib or wherever... which turns out to be quite tricky.)

Still fails the same for me.

That's extremely odd. What is the contents of /opt/emlix/test/sysroot/usr/lib? In particular, is libbfd.{so,a} of any description visible in there after the failed installation? Because it should be: bfd is always 'make install' before libctf, and you didn't specify --disable-install-libbfd.

(Maybe this is sysroot-related?)

Reinvoking the link command libtool says it's executing (in the libctf directory of the build tree) and adding -Wl,--verbose will give you a pile of output which will in part say where ld is looking for libraries. That might be informative, perhaps.

The Source Mage bug is probably a different problem again, and I think it's more a Source Mage problem really. It is in general not safe to remove toolchain binaries completely before 'make install' for precisely the reason shown here: a working toolchain may well be needed at installation time, since libtool can decide that it needs to invoke the compiler and linker during installation (this routinely happens for GCC, too). (This is distinct from the other problem in this bug, which is mostly about installing binutils without having .a/.so files from an existing binutils around, not about installing binutils without having a working ld at all.)

To me this feels like something the Source Mage package installer should deal with in another way. The simplest but ugliest approaches might be to *move* the old ld somewhere else and drop a temporary symlink into the GCC tooldir so that gcc still works at installation time, or by simply not removing the old linker at all. But the *right* approach is probably to do a 'make install' into a temporary DESTDIR, and only *then* remove the old toolchain and move the DESTDIRed stuff into place. This last option is what more or less every other package manager-driven build system does these days, and is essentially required for a wide variety of packages for safe installation, from glibc to Rust. So I suspect your build system can already do it, and just isn't doing it for binutils :) if it can't do it, it should learn, because installing glibc via a straight 'make install' is *dangerous* and is likely to lead to an out-of-sync ld.so and libc and a system on which every dynamically-linked binary fails to start.

(I don't see an obvious way to lift the requirement for a working linker at make install time without breaking invocation of built binaries from the build tree and thus breaking the testsuite, or reimplementing half of libtool badly inside the libctf testsuite, which seems even worse. This requirement is not new: it's as old as Libtool, and binutils-gdb triggered it for other packages even before now, notably GDB. Maybe you didn't notice this because you split GDB into a separate package, so the linker wasn't removed when that was installed.)

(... if Source Mage always removes packages before installing them, how does it install make or coreutils? I suppose I should download it and have a look!)

There is a /usr/bin/x86_64-linux-gnu-ld.bfd, which belongs to the host binutils. Otherwise I'm doing a cross-build and a DESTDIR install, so there is nothing that could get overwritten and destroyed during install.

I'll dig out the other information later.

... any movement on this?

Thanks for the ping, this somehow got lost. I retried with 2.38 and 2.39. It still fails the same. The contents of /opt/emlix/test/sysroot/usr/lib are:

crt1.o
crti.o
crtn.o
gconv
gcrt1.o
libanl.a
libanl_p.a
libanl.so
libasan.a
libasan.la
libasan_preinit.o
libasan.so
libasan.so.6
libasan.so.6.0.0
libatomic.a
libatomic.la
libatomic.so
libatomic.so.1
libatomic.so.1.2.0
libBrokenLocale.a
libBrokenLocale_p.a
libBrokenLocale.so
libc.a
libc_malloc_debug.so
libc_nonshared.a
libc_p.a
libcrypt.a
libcrypt_p.a
libcrypt.so
libc.so
libdl.a
libdl_p.a
libg.a
libgomp.a
libgomp.la
libgomp.so
libgomp.so.1
libgomp.so.1.0.0
libgomp.spec
libitm.a
libitm.la
libitm.so
libitm.so.1
libitm.so.1.0.0
libitm.spec
libm.a
libmcheck.a
libm_p.a
libm.so
libnss_compat.so
libnss_db.so
libnss_hesiod.so
libpthread.a
libpthread_p.a
libresolv.a
libresolv_p.a
libresolv.so
librt.a
librt_p.a
libsanitizer.spec
libssp.a
libssp.la
libssp_nonshared.a
libssp_nonshared.la
libssp.so
libssp.so.0
libssp.so.0.0.0
libstdc++.a
libstdc++fs.a
libstdc++fs.la
libstdc++.la
libstdc++.so
libstdc++.so.6
libstdc++.so.6.0.28
libsupc++.a
libsupc++.la
libthread_db.so
libubsan.a
libubsan.la
libubsan.so
libubsan.so.1
libubsan.so.1.0.0
libutil.a
libutil_p.a
Mcrt1.o
Scrt1.o

So, basically gcc and glibc.