| Summary: | Installation of 2.36 fails with 'LIBCTF_1.1 not found' followed by 'relink' suggestion | ||
|---|---|---|---|
| Product: | binutils | Reporter: | Joel <j-comm> |
| Component: | binutils | Assignee: | Nick Alcock <nick.alcock> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | nick.alcock |
| Priority: | P2 | ||
| Version: | 2.36 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | 2021-01-26 00:00:00 | |
| Attachments: |
Full output of configure, make, make check, make install
Fix ld-versus-libctf installation ordering |
||
|
Description
Joel
2021-01-26 15:07:43 UTC
This is exceptionally strange. (And needless to say is not ever supposed to happen!) Subsequent links are failiong because ld itself uses libctf: that part is understandable... the hard part is how the libctf you just linked can possibly not have the LIBCTF_1.1 version in it. It should be there! The output of readelf -V libctf/.libs/libctf.so (before the install) might be helpful in figuring out what on earth is going on. You are overwriting the ld program in your PATH, which was also configured to use for building. Ohhh I bet I know what it is. You'll need to roll back by sticking the old ld in place (I hope you have a copy) or roll forward by hand-copying .libs/libctf.so.0 into place in /usr/local. The problem is installation order: ld is being installed before libctf, but ld *uses* libctf and thus if libctf is relinked for any reason by the install phase, ld might find itself calling on symbols that aren't in the libctf already present on the system (if it even is there). Should have a fix for you to test in a few minutes. Created attachment 13159 [details]
Fix ld-versus-libctf installation ordering
> Should have a fix for you to test in a few minutes.
Thank you for this - I will try the patch and report results.
Fortunately, my rule whenever updating fundamental programs is to do a full backup before-hand, and rebuild in a standalone mode. This made it so recovering was a simple matter of restoring the drive from the backup.
The provided patch worked. Thank you! OK, I'll work on upstreaming it. The master branch has been updated by Nick Alcock <nix@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f04ce15e831b691d7610dba284e266919e757b10 commit f04ce15e831b691d7610dba284e266919e757b10 Author: Nick Alcock <nick.alcock@oracle.com> Date: Tue Jan 26 16:05:17 2021 +0000 ld: depend on libctf Since ld may depend on libctf (if present), and libctf may be relinked by the installation process, libctf must be installed before ld is, or the relink may fail if it calls on symbols or symbol versions that do not exist in any libctf already present on the system. (If none is present, the copy in the build tree will be automatically used, but if one *is* present, it may take precedence and break things.) (This is a maybe- dependency, so it will work even if libctf is disabled.) ChangeLog 2021-01-26 Nick Alcock <nick.alcock@oracle.com> PR 27250 * Makefile.def: Add install-libctf dependency to install-ld. * Makefile.in: Regenerated. On master and 2.36. |