compile failure due to undefined symbol

[Peter S. Mazinger]

On Fri, 28 Sep 2007, Nick Clifton wrote:

> Hi Peter,
> 
> 
> >>> libbfd.so (libtool problem) mentioned before LIBADD. Why not hardcoding 
> >>> the path to the right libbfd.so then ($(top_buildir)/bfd/libbfd.la)?
> >> Have you tried doing this ?  If so did it work for both native builds and cross 
> >> host builds ?
> > 
> > I did it natively, haven't checked on a cross build. I have used 
> > hardcoded libbfd.so path, since libbfd.la has libdir= set based on 
> > configure options already and I thought that libtool might fail to pick up 
> > the right one.
> 
> Hmm, OK, do you have a patch that I might try out then ?

Attached you'll find what I used, for convenience I have added a second 
patch, so that you do not need autotools. I do not know which binutils' ld 
began supporting -rpath-link, else -L"`pwd`/../bfd/.libs" could be used. 
I have used the versioned name instead of -lbfd, so that libbfd.la does 
not influence the result (the dependency is though on libbfd.a, the we 
can be sure that libbfd-VERSION.so is also present).
Replacing -rpath-link with -rpath would be maybe an option too, I haven't 
though checked if libtool links the first libopcodes.so in the build 
directory with the `pwd`/../bfd/.libs path and later on install relinking 
with -rpath $(libdir), probably to support this BFDLIB_HARDCODE has to be 
ignored in the second link.

Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binutils-2.18-zdefs_2.patch
Type: application/octet-stream
Size: 5021 bytes
Desc: 
URL: <https://sourceware.org/pipermail/binutils/attachments/20070928/81ad7ecb/attachment.obj>
-------------- next part --------------
--- binutils-2.18/opcodes/configure.in.mps	2007-09-28 12:49:56.000000000 +0200
+++ binutils-2.18/opcodes/configure.in	2007-09-28 12:49:24.000000000 +0200
@@ -99,6 +99,8 @@ using_cgen=no
 # Horrible hacks to build DLLs on Windows.
 WIN32LDFLAGS=
 WIN32LIBADD=
+BFDLIB_HARDCODE=
+BFDLIB=
 case "${host}" in
 *-*-cygwin*)
   if test "$enable_shared" = "yes"; then
@@ -106,9 +108,17 @@ case "${host}" in
     WIN32LIBADD="-L`pwd`/../bfd -lbfd -L`pwd`/../libiberty -liberty -L`pwd`/../intl -lintl -lcygwin"
   fi
   ;;
+*)
+  if test "${enable_shared}" = "yes"; then
+    BFDLIB_HARDCODE="-Wl,-rpath-link,`pwd`/../bfd/.libs -lbfd-${VERSION}"
+    BFDLIB="`pwd'/../bfd/libfd.la"
+  fi
+  ;;
 esac
 AC_SUBST(WIN32LDFLAGS)
 AC_SUBST(WIN32LIBADD)
+AC_SUBST(BFDLIB_HARDCODE)
+AC_SUBST(BFDLIB)
 
 # target-specific stuff:
 
--- binutils-2.18/opcodes/Makefile.am.mps	2007-09-28 12:50:16.000000000 +0200
+++ binutils-2.18/opcodes/Makefile.am	2007-09-28 12:54:22.000000000 +0200
@@ -367,8 +367,10 @@ libopcodes_la_SOURCES =  dis-buf.c disas
 # planned install directory of libbfd.  This can cause us to pick up an
 # old version of libbfd, or to pick up libbfd for the wrong architecture
 # if host != build.
-libopcodes_la_DEPENDENCIES = $(OFILES)
-libopcodes_la_LIBADD = $(OFILES) @WIN32LIBADD@
+# For the above case, we use a hardcoded path to libbfd.so instead of
+# relying on the entries in libbfd.la
+libopcodes_la_DEPENDENCIES = $(OFILES) @BFDLIB@
+libopcodes_la_LIBADD = $(OFILES) @WIN32LIBADD@ @BFDLIB_HARDCODE@
 libopcodes_la_LDFLAGS = -release `cat ../bfd/libtool-soversion` @WIN32LDFLAGS@
 
 # libtool will build .libs/libopcodes.a.  We create libopcodes.a in