https://sourceware.org/bugzilla/show_bug.cgi?id=27297
--- Comment #2 from Stephen Casner <casner at acm dot org> --- git bisect finds this is the commit where the problem began: commit 1038406a8f6609ad0a449746da70393b0835f699 Author: Nick Alcock <nick.alc...@oracle.com> Date: Tue Jan 5 13:25:56 2021 +0000 libctf: rip out BFD_DEPENDENCIES / BFD_LIBADD This complex morass inherited from libopcodes, which endeavours to implement the effect of specifying ../bfd/libbfd.la in _LIBADD without actually doing so, appears to be working around a libtool bug which as far as I can see is no longer present (i.e., the install directory no longer appears in -L arguments in libtool link-mode invocations, so there is no danger of picking up old libbfds or other dependent libraries). Replaced with a simple reference to libbfd.la in the appropriate place. Also adjusted things a little more so that libctf.la and libctf-nobfd.la are self-contained, even when linking statically. This opens up the possibility of running libtool to link against libctf from inside the (upcoming) testsuite. libctf/ChangeLog 2021-01-05 Nick Alcock <nick.alc...@oracle.com> * configure.ac (BFD_LIBADD): Remove. (BFD_DEPENDENCIES): Likewise. Remove associated cases. (SHARED_LIBADD): Rename to... (CTF_LIBADD): ... this. Stick in a suitable libiberty even when linking statically. * Makefile.am (libctf_nobfd_la_LIBADD): Adjust accordingly. libctf uses libintl. (libctf_la_LIBADD): Reference libbfd.la directly, not via BFD_LIBADD. (libctf_la_DEPENDENCIES): Remove. * Makefile.in: Regenerate. * configure: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.