libctf: link against libiberty before linking in libbfd or libctf-nobfd
authorNick Alcock <nick.alcock@oracle.com>
Mon, 27 Sep 2021 19:31:21 +0000 (20:31 +0100)
committerNick Alcock <nick.alcock@oracle.com>
Mon, 27 Sep 2021 19:31:22 +0000 (20:31 +0100)
commit7d53105d6ed984aec255fa0eacd0405f3c1bb874
treeb5de7c5ab7f38dec4586a73b5f0a91c507a00c3e
parent7f92ed6b41c441ab2111c9f1212cbbc13222edcc
libctf: link against libiberty before linking in libbfd or libctf-nobfd

This ensures that the CTF_LIBADD, which always contains at least this
when doing a shared link:

-L`pwd`/../libiberty/pic -liberty

appears in the link line before any requirements pulled in by libbfd.la,
which include -liberty but because it is install-time do not include the
-L`pwd`/../libiberty/pic portion (in an indirect dep like this, the path
comes from the libbfd.la file, and is an install path).  libiberty also
appears after libbfd in the link line by virtue of libctf-nobfd.la,
because libctf-nobfd has to follow libbfd in the link line, and that
needs symbols from libiberty too.

Without this, an installed liberty might well be pulled in by libbfd,
and if --enable-install-libiberty is not specified this libiberty might
be completely incompatible with what is being installed and break either
or boht of libbfd and libctf. (The specific problem observed here is
that bsearch_r was not present, but other problems might easily be
observed in future too.)

Because ld links against libctf, this has a tendency to break the system
linker at install time too, if installing with --prefix=/usr.  That's
quite unpleasant to recover from.

libctf/ChangeLog
2021-09-27  Nick Alcock  <nick.alcock@oracle.com>

PR libctf/27360
* Makefile.am (libctf_la_LIBADD): Link against libiberty
before pulling in libbfd.la or pulling in libctf-nobfd.la.
* Makefile.in: Regenerate.
libctf/ChangeLog
libctf/Makefile.am
libctf/Makefile.in