Bug 27305 - relinking libctf during install does not find libbfd
Summary: relinking libctf during install does not find libbfd
Status: WAITING
Alias: None
Product: binutils
Classification: Unclassified
Component: libctf (show other bugs)
Version: 2.36
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-01 10:07 UTC by Rolf Eike Beer
Modified: 2021-06-24 08:57 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2021-06-15 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rolf Eike Beer 2021-02-01 10:07:28 UTC
I'm cross-building 2.36 and get this error:

libtool: relink: powerpc-unknown-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/opt/emlix/test/sysroot/usr/lib -lbfd -L/tmp/e2/build/binutils-target/bfd/../libiberty/pic -L/tmp/e2/build/binutils-target/zlib -L/tmp/e2/build/binutils-target/libctf/../libiberty/pic -liberty -lz -ldl  -Wl,--no-copy-dt-needed-entries -Wl,--as-needed -Wl,--build-id -Wl,--version-script=./libctf.ver   -Wl,-soname -Wl,libctf.so.0 -o .libs/libctf.so.0.0.0
/opt/emlix/test/lib/gcc/powerpc-unknown-linux-gnu/10.2.0/../../../../powerpc-unknown-linux-gnu/bin/ld: cannot find -lbfd
collect2: error: ld returned 1 exit status
libtool: install: error: relink `libctf.la' with the above command before installing it
Makefile:551: recipe for target 'install-libLTLIBRARIES' failed
make[3]: *** [install-libLTLIBRARIES] Error 1

The patch for bug 27250 is applied. The interesting part is also: before that patch it seems to build with "-j1", but breaks with "-j10", and now it reliably breaks every time.

The build was configured as:

./configure --build=x86_64-pc-linux-gnu --host=powerpc-unknown-linux-gnu --target=powerpc-unknown-linux-gnu --prefix=/usr --disable-werror --enable-deterministic-archives --disable-static --disable-nls --enable-shared --enable-install-libiberty
Comment 1 wich 2021-02-22 13:44:14 UTC
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.
Comment 2 Nick Alcock 2021-06-15 19:14:11 UTC
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.)
Comment 3 Rolf Eike Beer 2021-06-16 07:57:02 UTC
Still fails the same for me.
Comment 4 Nick Alcock 2021-06-16 13:47:31 UTC
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.
Comment 5 Nick Alcock 2021-06-16 13:57:59 UTC
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.)
Comment 6 Nick Alcock 2021-06-16 14:03:15 UTC
(... 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!)
Comment 7 Rolf Eike Beer 2021-06-17 05:17:22 UTC
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.