[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug libctf/27305] relinking libctf during install does not find libbfd

From: nick.alcock at oracle dot com
Subject: [Bug libctf/27305] relinking libctf during install does not find libbfd
Date: Wed, 16 Jun 2021 13:57:59 +0000


--- Comment #5 from Nick Alcock <nick.alcock at oracle dot com> ---
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

You are receiving this mail because:
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]