https://sourceware.org/bugzilla/show_bug.cgi?id=27305
--- 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 installed.) -- You are receiving this mail because: You are on the CC list for the bug.
