aboutsummaryrefslogtreecommitdiff
path: root/opcodes/configure
diff options
context:
space:
mode:
authorMaciej W. Rozycki <macro@embecosm.com>2021-10-27 12:21:14 +0100
committerMaciej W. Rozycki <macro@embecosm.com>2021-10-27 12:21:14 +0100
commit2b677209fe127b44c1920779a6fca2598c66c1d3 (patch)
treecffc48a1f33fc4839bc76e4981633c5554ae1e8f /opcodes/configure
parent28c26ce5fddaf21692c077b5b366a95bce991d64 (diff)
downloadgdb-2b677209fe127b44c1920779a6fca2598c66c1d3.zip
gdb-2b677209fe127b44c1920779a6fca2598c66c1d3.tar.gz
gdb-2b677209fe127b44c1920779a6fca2598c66c1d3.tar.bz2
opcodes: Fix RPATH not being set for dynamic libbfd dependency
If built as a shared library, libopcodes has a load-time dependency on libbfd, which is recorded in the dynamic section, however without a corresponding RPATH entry for the directory to find libbfd in. This causes loading to fail whenever libbfd is only pulled by libopcodes indirectly and libbfd has been installed in a directory that is not in the dynamic loader's search path. It does not happen with the programs included with binutils or GDB, because they all also pull libbfd when using libopcodes, but it can happen with external software, e.g.: $ gdbserver --help gdbserver: error while loading shared libraries: libbfd-[...].so: cannot open shared object file: No such file or directory $ (not our `gdbserver'). Indirect dynamic dependencies are handled by libtool automatically by adding RPATH entries as required, however our setup for libopcodes prevents this from happening by linking in libbfd with an explicit file reference sneaked through to the linker directly behind libtool's back via the `-Wl' linker command-line option rather than via `-l' combined with a suitable library search path specified via `-L', as it would be usually the case, or just referring to the relevant .la file in a fully libtool-enabled configuration such as ours. According to an observation in the discussion back in 2007[1][2][3] that has led to the current arrangement it is to prevent libtool from picking up the wrong version of libbfd. It does not appear to be needed though, not at least with our current libtool incarnation, as directly referring `libbfd.la' does exactly what it should, as previously suggested[4], and with no link-time reference to the installation directory other than to set RPATH. Uninstalled version of libopcodes has libbfd's build-time location prepended to RPATH too, as also expected. Use a direct reference to `libbfd.la' then, making the load error quoted above go away. Alternatively `-L' and `-l' could be used to the same effect, but it seems an unnecessary complication and just another way to circumvent rather than making use of libtool. References: [1] "compile failure due to undefined symbol", <https://sourceware.org/ml/binutils/2007-08/msg00476.html> [2] same, <https://sourceware.org/ml/binutils/2007-09/msg00000.html> [3] same, <https://sourceware.org/ml/binutils/2007-10/msg00019.html> [4] same, <https://sourceware.org/ml/binutils/2007-10/msg00034.html> opcodes/ * Makefile.am: Remove obsolete comment. * configure.ac: Refer `libbfd.la' to link shared BFD library except for Cygwin. * Makefile.in: Regenerate. * configure: Regenerate.
Diffstat (limited to 'opcodes/configure')
-rwxr-xr-xopcodes/configure13
1 files changed, 1 insertions, 12 deletions
diff --git a/opcodes/configure b/opcodes/configure
index 22a9cf9..acfbdd6 100755
--- a/opcodes/configure
+++ b/opcodes/configure
@@ -12133,19 +12133,8 @@ if test "$enable_shared" = "yes"; then
SHARED_LDFLAGS="-no-undefined"
SHARED_LIBADD="-L`pwd`/../bfd -lbfd -L`pwd`/../libiberty -liberty $SHARED_LIBADD"
;;
- *-*-darwin*)
- SHARED_LIBADD="-Wl,`pwd`/../bfd/.libs/libbfd.dylib ${SHARED_LIBADD}"
- SHARED_DEPENDENCIES="../bfd/libbfd.la"
- ;;
*)
- case "$host_vendor" in
- hp)
- SHARED_LIBADD="-Wl,`pwd`/../bfd/.libs/libbfd.sl ${SHARED_LIBADD}"
- ;;
- *)
- SHARED_LIBADD="-Wl,`pwd`/../bfd/.libs/libbfd.so ${SHARED_LIBADD}"
- ;;
- esac
+ SHARED_LIBADD="../bfd/libbfd.la ${SHARED_LIBADD}"
SHARED_DEPENDENCIES="../bfd/libbfd.la"
;;
esac