compile failure due to undefined symbol

compile failure due to undefined symbol

[Peter S. Mazinger]

Hello!

if LDFLAGS="-Wl,-z,defs", binutils fails to compile, since 
opcodes/disassemble.c uses bfd_get_arch(), but that is defined in
libbfd.so.
Should the opcode library be linked against libbfd as well?

Thanks, 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

Re: compile failure due to undefined symbol

[Alan Modra]

On Fri, Aug 31, 2007 at 02:26:08PM +0200, Peter S. Mazinger wrote:
> Should the opcode library be linked against libbfd as well?

Yes.

-- 
Alan Modra
Australia Development Lab, IBM

Re: compile failure due to undefined symbol

[Peter S. Mazinger]

On Sat, 1 Sep 2007, Alan Modra wrote:

> On Fri, Aug 31, 2007 at 02:26:08PM +0200, Peter S. Mazinger wrote:
> > Should the opcode library be linked against libbfd as well?
> 
> Yes.

ok, but there is a comment about having problems to "catch" the right 
libbfd.so (libtool problem) mentioned before LIBADD. Why not hardcoding 
the path to the right libbfd.so then ($(top_buildir)/bfd/libbfd.la)?

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

Re: compile failure due to undefined symbol

[Nick Clifton]

Hi Peter,

>>> Should the opcode library be linked against libbfd as well?
>> Yes.
> 
> ok, but there is a comment about having problems to "catch" the right 
> 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 ?

Cheers
   Nick

Re: compile failure due to undefined symbol

[Peter S. Mazinger]

On Fri, 28 Sep 2007, Nick Clifton wrote:

> Hi Peter,
> 
> >>> Should the opcode library be linked against libbfd as well?
> >> Yes.
> > 
> > ok, but there is a comment about having problems to "catch" the right 
> > 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.

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

Re: compile failure due to undefined symbol

[Nick Clifton]

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 ?

Cheers
   Nick

Re: compile failure due to undefined symbol

[Peter S. Mazinger]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1522 bytes --]

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

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 5021 bytes --]

--- binutils-2.18/opcodes/configure.mps	2007-09-28 13:00:32.000000000 +0200
+++ binutils-2.18/opcodes/configure	2007-09-28 13:03:15.000000000 +0200
@@ -458,7 +458,7 @@ ac_includes_default="\
 # include <unistd.h>
 #endif"
 
-ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build build_cpu build_vendor build_os host host_cpu host_vendor host_os target target_cpu target_vendor target_os CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA CYGPATH_W PACKAGE VERSION ACLOCAL AUTOCONF AUTOMAKE AUTOHEADER MAKEINFO install_sh STRIP ac_ct_STRIP INSTALL_STRIP_PROGRAM mkdir_p AWK SET_MAKE am__leading_dot AMTAR am__tar am__untar DEPDIR am__include am__quote AMDEP_TRUE AMDEP_FALSE AMDEPBACKSLASH CCDEPMODE am__fastdepCC_TRUE am__fastdepCC_FALSE AR ac_ct_AR RANLIB ac_ct_RANLIB LIBTOOL SED EGREP FGREP GREP LD DUMPBIN ac_ct_DUMPBIN NM LN_S lt_ECHO CPP WARN_CFLAGS NO_WERROR MAINTAINER_MODE_TRUE MAINTAINER_MODE_FALSE MAINT INSTALL_LIBBFD_TRUE INSTALL_LIBBFD_FALSE host_noncanonical target_noncanonical bfdlibdir bfdincludedir USE_NLS LIBINTL LIBINTL_DEP INCINTL XGETTEXT GMSGFMT POSUB CATALOGS DATADIRNAME INSTOBJEXT GENCAT CATOBJEXT MKINSTALLDIRS MSGFMT MSGMERGE CC_FOR_BUILD EXEEXT_FOR_BUILD HDEFINES CGEN_MAINT_TRUE CGEN_MAINT_FALSE cgendir WIN32LDFLAGS WIN32LIBADD archdefs BFD_MACHINES LIBOBJS LTLIBOBJS'
+ac_subst_vars='SHELL PATH_SEPARATOR PACKAGE_NAME PACKAGE_TARNAME PACKAGE_VERSION PACKAGE_STRING PACKAGE_BUGREPORT exec_prefix prefix program_transform_name bindir sbindir libexecdir datadir sysconfdir sharedstatedir localstatedir libdir includedir oldincludedir infodir mandir build_alias host_alias target_alias DEFS ECHO_C ECHO_N ECHO_T LIBS build build_cpu build_vendor build_os host host_cpu host_vendor host_os target target_cpu target_vendor target_os CC CFLAGS LDFLAGS CPPFLAGS ac_ct_CC EXEEXT OBJEXT INSTALL_PROGRAM INSTALL_SCRIPT INSTALL_DATA CYGPATH_W PACKAGE VERSION ACLOCAL AUTOCONF AUTOMAKE AUTOHEADER MAKEINFO install_sh STRIP ac_ct_STRIP INSTALL_STRIP_PROGRAM mkdir_p AWK SET_MAKE am__leading_dot AMTAR am__tar am__untar DEPDIR am__include am__quote AMDEP_TRUE AMDEP_FALSE AMDEPBACKSLASH CCDEPMODE am__fastdepCC_TRUE am__fastdepCC_FALSE AR ac_ct_AR RANLIB ac_ct_RANLIB LIBTOOL SED EGREP FGREP GREP LD DUMPBIN ac_ct_DUMPBIN NM LN_S lt_ECHO CPP WARN_CFLAGS NO_WERROR MAINTAINER_MODE_TRUE MAINTAINER_MODE_FALSE MAINT INSTALL_LIBBFD_TRUE INSTALL_LIBBFD_FALSE host_noncanonical target_noncanonical bfdlibdir bfdincludedir USE_NLS LIBINTL LIBINTL_DEP INCINTL XGETTEXT GMSGFMT POSUB CATALOGS DATADIRNAME INSTOBJEXT GENCAT CATOBJEXT MKINSTALLDIRS MSGFMT MSGMERGE CC_FOR_BUILD EXEEXT_FOR_BUILD HDEFINES CGEN_MAINT_TRUE CGEN_MAINT_FALSE cgendir WIN32LDFLAGS WIN32LIBADD BFDLIB_HARDCODE BFDLIB archdefs BFD_MACHINES LIBOBJS LTLIBOBJS'
 ac_subst_files=''
 
 # Initialize some variables set by options.
@@ -11359,6 +11359,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
@@ -11366,6 +11368,12 @@ 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/libbfd.la"
+  fi
+  ;;
 esac
 
 
@@ -12550,6 +12558,8 @@ s,@CGEN_MAINT_FALSE@,$CGEN_MAINT_FALSE,;
 s,@cgendir@,$cgendir,;t t
 s,@WIN32LDFLAGS@,$WIN32LDFLAGS,;t t
 s,@WIN32LIBADD@,$WIN32LIBADD,;t t
+s,@BFDLIB_HARDCODE@,$BFDLIB_HARDCODE,;t t
+s,@BFDLIB@,$BFDLIB,;t t
 s,@archdefs@,$archdefs,;t t
 s,@BFD_MACHINES@,$BFD_MACHINES,;t t
 s,@LIBOBJS@,$LIBOBJS,;t t
--- binutils-2.18/opcodes/Makefile.in.mps	2007-09-28 13:03:24.000000000 +0200
+++ binutils-2.18/opcodes/Makefile.in	2007-09-28 13:04:16.000000000 +0200
@@ -183,6 +183,8 @@ VERSION = @VERSION@
 WARN_CFLAGS = @WARN_CFLAGS@
 WIN32LDFLAGS = @WIN32LDFLAGS@
 WIN32LIBADD = @WIN32LIBADD@
+BFDLIB_HARDCODE = @BFDLIB_HARDCODE@
+BFDLIB = @BFDLIB@
 XGETTEXT = @XGETTEXT@
 ac_ct_CC = @ac_ct_CC@
 ac_ct_DUMPBIN = @ac_ct_DUMPBIN@
@@ -590,8 +592,8 @@ libopcodes_la_SOURCES = dis-buf.c disass
 # 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@
+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

[-- Attachment #3: Type: TEXT/PLAIN, Size: 1703 bytes --]

--- 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

Re: compile failure due to undefined symbol

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 748 bytes --]

Hi Peter,

> Attached you'll find what I used

I could not get that patch to work for me.  (The inclusion of -lbfd-${VERSION} 
did not work because VERSION only expanded into -lbfd-2.18.50 and not 
-lbfd-2.18.50-20071002, and the definition of BFDLIB had only one back-tick not 
two).

But I was able to use it as the basis for a patch which did work.  Would you 
like to try it out and see what you think ?  (The patch is attached, but I have 
not included the regenerated files.  I assume that you are OK to recreate them 
yourself).  I chose to use -rpath rather than -rpath-link and then to 
explicitly link into the shared bfd library rather than using the library 
location mechanism as this appeared to do the right thing.

Cheers
   Nick



[-- Attachment #2: shared-libopcodes.patch --]
[-- Type: text/x-patch, Size: 3153 bytes --]

Index: opcodes/configure.in
===================================================================
RCS file: /cvs/src/src/opcodes/configure.in,v
retrieving revision 1.78
diff -c -3 -p -r1.78 configure.in
*** opcodes/configure.in	9 Sep 2007 01:22:57 -0000	1.78
--- opcodes/configure.in	2 Oct 2007 10:18:23 -0000
*************** AC_SUBST(cgendir)
*** 97,115 ****
  
  using_cgen=no
  
! # Horrible hacks to build DLLs on Windows.
! WIN32LDFLAGS=
! WIN32LIBADD=
! case "${host}" in
! *-*-cygwin*)
!   if test "$enable_shared" = "yes"; then
!     WIN32LDFLAGS="-no-undefined"
!     WIN32LIBADD="-L`pwd`/../bfd -lbfd -L`pwd`/../libiberty -liberty -L`pwd`/../intl -lintl -lcygwin"
!   fi
!   ;;
! esac
! AC_SUBST(WIN32LDFLAGS)
! AC_SUBST(WIN32LIBADD)
  
  # target-specific stuff:
  
--- 97,122 ----
  
  using_cgen=no
  
! # Horrible hacks to build DLLs on Windows and a shared library elsewhere.
! SHARED_LDFLAGS=
! SHARED_LIBADD=
! SHARED_DEPENDENCIES=
! if test "$enable_shared" = "yes"; then
!   case "${host}" in
!     *-*-cygwin*)
!       SHARED_LDFLAGS="-no-undefined"
!       SHARED_LIBADD="-L`pwd`/../bfd -lbfd -L`pwd`/../libiberty -liberty -L`pwd`/../intl -lintl -lcygwin"
!       ;;
!     *)
!       SHARED_LDFLAGS="-Wl,-z,defs"
!       SHARED_LIBADD="-Wl,`pwd`/../bfd/.libs/libbfd.so"
!       SHARED_DEPENDENCIES="`pwd`/../bfd/.libs/libbfd.so"
!       ;;
!   esac
! fi
! AC_SUBST(SHARED_LDFLAGS)
! AC_SUBST(SHARED_LIBADD)
! AC_SUBST(SHARED_DEPENDENCIES)
  
  # target-specific stuff:
  
Index: opcodes/Makefile.am
===================================================================
RCS file: /cvs/src/src/opcodes/Makefile.am,v
retrieving revision 1.121
diff -c -3 -p -r1.121 Makefile.am
*** opcodes/Makefile.am	14 Sep 2007 19:28:56 -0000	1.121
--- opcodes/Makefile.am	2 Oct 2007 10:18:23 -0000
*************** libopcodes_la_SOURCES =  dis-buf.c disas
*** 367,376 ****
  # Unfortunately this causes libtool to add -L$(libdir), referring to the
  # 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@
! libopcodes_la_LDFLAGS = -release `cat ../bfd/libtool-soversion` @WIN32LDFLAGS@
  
  # libtool will build .libs/libopcodes.a.  We create libopcodes.a in
  # the build directory so that we don't have to convert all the
--- 367,377 ----
  # Unfortunately this causes libtool to add -L$(libdir), referring to the
  # 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. So for building with shared libraries we use a
! # hardcoded path to libbfd.so instead of relying on the entries in libbfd.la.
! libopcodes_la_DEPENDENCIES = $(OFILES) @SHARED_DEPENDENCIES@
! libopcodes_la_LIBADD = $(OFILES) @SHARED_LIBADD@
! libopcodes_la_LDFLAGS = -release `cat ../bfd/libtool-soversion` @SHARED_LDFLAGS@
  
  # libtool will build .libs/libopcodes.a.  We create libopcodes.a in
  # the build directory so that we don't have to convert all the

Re: compile failure due to undefined symbol

[Peter S. Mazinger]

On Tue, 2 Oct 2007, Nick Clifton wrote:

> Hi Peter,
> 
> > Attached you'll find what I used
> 
> I could not get that patch to work for me.  (The inclusion of -lbfd-${VERSION} 
> did not work because VERSION only expanded into -lbfd-2.18.50 and not 
> -lbfd-2.18.50-20071002, and the definition of BFDLIB had only one back-tick not 
> two).

tested only on 2.18, not a subversioned one

> But I was able to use it as the basis for a patch which did work.  Would you 
> like to try it out and see what you think ?  (The patch is attached, but I have 
> not included the regenerated files.  I assume that you are OK to recreate them 
> yourself).  I chose to use -rpath rather than -rpath-link and then to 
> explicitly link into the shared bfd library rather than using the library 
> location mechanism as this appeared to do the right thing.

I assume you checked that using -rpath has really the correct 
RPATH/RUNPATH in opcodes/.libs/libopcodes.so and in the finally installed 
one in --libdir or whatever.

Wondering if SHARED_DEPENDENCIES should be bfd/libbfd.la, that is for sure 
a target in the Makefiles and implies the creation of the needed 
libbfd.so, meaning also that the bfd directory is "finalized", I am 
sure about bfd/.libs/libbfd.so being a good target.

Will check your patch, thanks

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

Re: compile failure due to undefined symbol

[Peter S. Mazinger]

On Tue, 2 Oct 2007, Peter S. Mazinger wrote:

Hi Nick,

[snip]
> > But I was able to use it as the basis for a patch which did work.  Would you 
> > like to try it out and see what you think ?  (The patch is attached, but I have 
> > not included the regenerated files.  I assume that you are OK to recreate them 
> > yourself).  I chose to use -rpath rather than -rpath-link and then to 
> > explicitly link into the shared bfd library rather than using the library 
> > location mechanism as this appeared to do the right thing.

Works for me too with 2.18 for i686-*-linux-gnu/ and 2.17 for
mipsel-*-linux-uclibc (adapted).

Is -Wl,-z,defs supported everywhere?

> I assume you checked that using -rpath has really the correct 
> RPATH/RUNPATH in opcodes/.libs/libopcodes.so and in the finally installed 
> one in --libdir or whatever.

I checked, there is no hardcoded RUNPATH/RPATH in the intermediate/final 
shared libraries, so that should be fine

> Wondering if SHARED_DEPENDENCIES should be bfd/libbfd.la, that is for sure 
> a target in the Makefiles and implies the creation of the needed 
> libbfd.so, meaning also that the bfd directory is "finalized", I am 
> sure about bfd/.libs/libbfd.so being a good target.

I have used SHARED_DEPENDENCIES pointing to `pwd`/../bfd/libbfd.la

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

Re: compile failure due to undefined symbol

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

Hi Peter,

> I have used SHARED_DEPENDENCIES pointing to `pwd`/../bfd/libbfd.la

Right.  I should have been using that.

Here is the patch that I have checked in.

Cheers
   Nick

opcodes/ChangeLog
2007-10-04  Nick Clifton  <nickc@redhat.com>

	* configure.in (WIN32LDFLAGS): Rename to SHARED_LDFLAGS.
	(WIN32LIBADD): Rename to SHARED_LIBADD
	(SHARED_DEPENDENCIES): New exported variable.
	(enable_shared): Add dependency upon libbfd.la for non-cygwin
	based shared library builds.
	* Makefile.am (libopcodes_la_DEPENDENCIES): Append
	SHARED_DEPENDENCIES.
	(libopcodes_la_LIBADD): Rename WIN32LIBADD to SHARED_LIBADD.
	(libopcodes_la_LDFLAGS): Rename WIN32LDFLAGS to SHARED_LDFLAGS.
	* configure: Regenerate.
	* Makefile.in: Regenerate.

[-- Attachment #2: shared-libopcodes.patch --]
[-- Type: text/x-patch, Size: 3115 bytes --]

Index: opcodes/configure.in
===================================================================
RCS file: /cvs/src/src/opcodes/configure.in,v
retrieving revision 1.78
diff -c -3 -p -r1.78 configure.in
*** opcodes/configure.in	9 Sep 2007 01:22:57 -0000	1.78
--- opcodes/configure.in	4 Oct 2007 13:58:40 -0000
*************** AC_SUBST(cgendir)
*** 97,115 ****
  
  using_cgen=no
  
! # Horrible hacks to build DLLs on Windows.
! WIN32LDFLAGS=
! WIN32LIBADD=
! case "${host}" in
! *-*-cygwin*)
!   if test "$enable_shared" = "yes"; then
!     WIN32LDFLAGS="-no-undefined"
!     WIN32LIBADD="-L`pwd`/../bfd -lbfd -L`pwd`/../libiberty -liberty -L`pwd`/../intl -lintl -lcygwin"
!   fi
!   ;;
! esac
! AC_SUBST(WIN32LDFLAGS)
! AC_SUBST(WIN32LIBADD)
  
  # target-specific stuff:
  
--- 97,121 ----
  
  using_cgen=no
  
! # Horrible hacks to build DLLs on Windows and a shared library elsewhere.
! SHARED_LDFLAGS=
! SHARED_LIBADD=
! SHARED_DEPENDENCIES=
! if test "$enable_shared" = "yes"; then
!   case "${host}" in
!     *-*-cygwin*)
!       SHARED_LDFLAGS="-no-undefined"
!       SHARED_LIBADD="-L`pwd`/../bfd -lbfd -L`pwd`/../libiberty -liberty -L`pwd`/../intl -lintl -lcygwin"
!       ;;
!     *)
!       SHARED_LIBADD="-Wl,`pwd`/../bfd/.libs/libbfd.so"
!       SHARED_DEPENDENCIES="`pwd`/../bfd/.libs/libbfd.la"
!       ;;
!   esac
! fi
! AC_SUBST(SHARED_LDFLAGS)
! AC_SUBST(SHARED_LIBADD)
! AC_SUBST(SHARED_DEPENDENCIES)
  
  # target-specific stuff:
  
Index: opcodes/Makefile.am
===================================================================
RCS file: /cvs/src/src/opcodes/Makefile.am,v
retrieving revision 1.121
diff -c -3 -p -r1.121 Makefile.am
*** opcodes/Makefile.am	14 Sep 2007 19:28:56 -0000	1.121
--- opcodes/Makefile.am	4 Oct 2007 13:58:40 -0000
*************** libopcodes_la_SOURCES =  dis-buf.c disas
*** 367,376 ****
  # Unfortunately this causes libtool to add -L$(libdir), referring to the
  # 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@
! libopcodes_la_LDFLAGS = -release `cat ../bfd/libtool-soversion` @WIN32LDFLAGS@
  
  # libtool will build .libs/libopcodes.a.  We create libopcodes.a in
  # the build directory so that we don't have to convert all the
--- 367,377 ----
  # Unfortunately this causes libtool to add -L$(libdir), referring to the
  # 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. So for building with shared libraries we use a
! # hardcoded path to libbfd.so instead of relying on the entries in libbfd.la.
! libopcodes_la_DEPENDENCIES = $(OFILES) @SHARED_DEPENDENCIES@
! libopcodes_la_LIBADD = $(OFILES) @SHARED_LIBADD@
! libopcodes_la_LDFLAGS = -release `cat ../bfd/libtool-soversion` @SHARED_LDFLAGS@
  
  # libtool will build .libs/libopcodes.a.  We create libopcodes.a in
  # the build directory so that we don't have to convert all the

Re: compile failure due to undefined symbol

[Peter S. Mazinger]

On Thu, 4 Oct 2007, Nick Clifton wrote:

> Hi Peter,
> 
> > I have used SHARED_DEPENDENCIES pointing to `pwd`/../bfd/libbfd.la

Hi Nick,

you used `pwd`/../bfd/.libs/libbfd.la, I used `pwd`/../bfd/libbfd.la, note 
the missing .libs subdir, maybe it does not matter though

> Right.  I should have been using that.
> 
> Here is the patch that I have checked in.

Thanks, 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

Re: compile failure due to undefined symbol

[Nick Clifton]

Hi Peter,

> you used `pwd`/../bfd/.libs/libbfd.la, I used `pwd`/../bfd/libbfd.la, note 
> the missing .libs subdir, maybe it does not matter though

bfd/.libs/libbfd.la is a symbolic link to bfd/libbbfd.la so it should be OK.

Cheers
   Nick

Re: compile failure due to undefined symbol

[Peter S. Mazinger]

On Thu, 4 Oct 2007, Nick Clifton wrote:

> Hi Peter,
> 
> > you used `pwd`/../bfd/.libs/libbfd.la, I used `pwd`/../bfd/libbfd.la, note 
> > the missing .libs subdir, maybe it does not matter though
> 
> bfd/.libs/libbfd.la is a symbolic link to bfd/libbbfd.la so it should be OK.

I know that, I have thought, that the "last" target in bfd subdir is 
bfd/libbfd.la, to be sure that everything is compiled (and parallel builds 
do not break remain parallel)

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

Re: compile failure due to undefined symbol

[Peter S. Mazinger]

On Thu, 4 Oct 2007, Peter S. Mazinger wrote:

Hi Nick,

> On Thu, 4 Oct 2007, Nick Clifton wrote:
> 
> > Hi Peter,
> > 
> > > you used `pwd`/../bfd/.libs/libbfd.la, I used `pwd`/../bfd/libbfd.la, note 
> > > the missing .libs subdir, maybe it does not matter though
> > 
> > bfd/.libs/libbfd.la is a symbolic link to bfd/libbbfd.la so it should be OK.
> 
> I know that, I have thought, that the "last" target in bfd subdir is 
> bfd/libbfd.la, to be sure that everything is compiled (and parallel builds 
> do not break remain parallel)

I rechecked all subdirs around DEPENDENCIES, binutils/gas/grof/ld have 
dependencies on ../bfd/libbfd.la (relative path), so that could be good 
for opcodes too.

I did following to see if it works:
mkdir build; cd build; path_to_configure/configure; make
cd bfd; make clean; cd ../opcodes; make clean; make
(the first make and the make clean's can be omitted, only there for 
completeness, if used in an already compiled build directory)

2 dependencies not found ../bfd/bfd.h and ../bfd/.libs/libbfd.la

Test of which targets exist at least in the bfd subdir:
cd ../bfd;
make bfd.h and make libbfd.la are ok (or from the build dir using make -C 
bfd bfd.h libbfd.la), but make [./].libs/libbfd.so [./].libs/libbfd.la fail 
all four, there are definitely no such targets, so I propose changing 
absolute path to relative (../bfd/libbfd.la) as dependency as that is at 
least used everywhere (even if it is not quite working).

Fixing the dependencies themselves is a generic issue, none of the 
dependencies work as target (checked ../bfd/bfd.h, 
../libiberty/libiberty.a called from the subdirs where they are used). 
The build copes with this probably due to the compile order, but 
effectively dependendencies are incorrect, they should really create the 
missing files, if ran from somewhere else. Targets like:
../bfd/bfd.h:
	(cd ../bfd; make bfd.h)

or

../libiberty.a:
	(cd ..; make -C libiberty libiberty.a)

are needed in some generic place, seen by all makefiles

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

Re: compile failure due to undefined symbol

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 114 bytes --]

Hi Peter,

   OK, so sorry if I am being dense here.  Will this patch fix things for opcodes ?

Cheers
   Nick




[-- Attachment #2: configure.in.patch --]
[-- Type: text/x-patch, Size: 713 bytes --]

Index: opcodes/configure.in
===================================================================
RCS file: /cvs/src/src/opcodes/configure.in,v
retrieving revision 1.79
diff -c -3 -p -r1.79 configure.in
*** opcodes/configure.in	4 Oct 2007 14:06:40 -0000	1.79
--- opcodes/configure.in	8 Oct 2007 10:41:14 -0000
*************** if test "$enable_shared" = "yes"; then
*** 109,115 ****
        ;;
      *)
        SHARED_LIBADD="-Wl,`pwd`/../bfd/.libs/libbfd.so"
!       SHARED_DEPENDENCIES="`pwd`/../bfd/.libs/libbfd.la"
        ;;
    esac
  fi
--- 109,115 ----
        ;;
      *)
        SHARED_LIBADD="-Wl,`pwd`/../bfd/.libs/libbfd.so"
!       SHARED_DEPENDENCIES="`pwd`/../bfd/libbfd.la"
        ;;
    esac
  fi

Re: compile failure due to undefined symbol

[Peter S. Mazinger]

On Mon, 8 Oct 2007, Nick Clifton wrote:

> Hi Peter,
> 
>    OK, so sorry if I am being dense here.  Will this patch fix things for opcodes ?
> 
> Cheers
>    Nick

Hello Nick,

yes, at least we have opcodes the same as all the others

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

Re: compile failure due to undefined symbol

[Peter S. Mazinger]

On Mon, 8 Oct 2007, Peter S. Mazinger wrote:

> On Mon, 8 Oct 2007, Nick Clifton wrote:
> 
> > Hi Peter,
> > 
> >    OK, so sorry if I am being dense here.  Will this patch fix things for opcodes ?
> > 
> > Cheers
> >    Nick
> 
> Hello Nick,
> 
> yes, at least we have opcodes the same as all the others

Sorry, a relative path is what is used everywhere (without `pwd`)

../bfd/libbfd.la

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

Re: compile failure due to undefined symbol

[Nick Clifton]

Hi Peter,

> Sorry, a relative path is what is used everywhere (without `pwd`)
> 
> ../bfd/libbfd.la

Right, that is what I have checked in then.

Cheers
   Nick

Re: compile failure due to undefined symbol

[Daniel Jacobowitz]

On Tue, Oct 02, 2007 at 11:57:03AM +0100, Nick Clifton wrote:
> But I was able to use it as the basis for a patch which did work.  Would you 
> like to try it out and see what you think ?  (The patch is attached, but I have 
> not included the regenerated files.  I assume that you are OK to recreate them 
> yourself).  I chose to use -rpath rather than -rpath-link and then to 
> explicitly link into the shared bfd library rather than using the library 
> location mechanism as this appeared to do the right thing.

Eww eww eww!  What, if anything, does this do to the installed
libraries?

-- 
Daniel Jacobowitz
CodeSourcery

Re: compile failure due to undefined symbol

[Nick Clifton]

Hi Daniel,

> Eww eww eww!  What, if anything, does this do to the installed
> libraries?

I think they are OK.  (I am not an expert in this area though, so please do 
correct me if I am wrong).  I tried running an installed executable and that 
worked:

   % cd shared-build/install/bin
   % ./objdump -f ./objdump
   ./objdump:     file format elf64-x86-64
   architecture: i386:x86-64, flags 0x00000112:
   EXEC_P, HAS_SYMS, D_PAGED
   start address 0x0000000000403370

And checking its dependencies:

   % ldd ./objdump
   libopcodes-2.18.50.20071002.so => 
/work/builds/binutils/current/shared-build/install/lib/libopcodes-2.18.50.20071002.so 
(0x0000002a95557000)
   libbfd-2.18.50.20071002.so => 
/work/builds/binutils/current/shared-build/install/lib/libbfd-2.18.50.20071002.so 
(0x0000002a956d1000)
   libc.so.6 => /lib64/tls/libc.so.6 (0x0000003d51f00000)
   /lib64/ld-linux-x86-64.so.2 (0x0000003d51d00000)

Plus running ldd on the installed library seemed to be OK:

   % ldd ../lib/libopcodes.so
   libbfd-2.18.50.20071002.so => 
/work/builds/binutils/current/shared-build/opcodes/../bfd/.libs/libbfd-2.18.50.20071002.so 
(0x0000002a956d1000)
   libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a958ba000)
   /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)

What else should I do to test the library ?

Cheers
   Nick

Re: compile failure due to undefined symbol

[Daniel Jacobowitz]

On Tue, Oct 02, 2007 at 03:24:14PM +0100, Nick Clifton wrote:
> What else should I do to test the library ?

What dynamic tags (readelf -d) does it have before and after?  If your
patch has no effect on the dynamic tags of installed libraries, then
it's surely fine; it only affects running things from the build
directory.  But if it adds an rpath to the installed libraries, I
think we should avoid that.

-- 
Daniel Jacobowitz
CodeSourcery

Re: compile failure due to undefined symbol

[Nick Clifton]

Hi Daniel,

> What dynamic tags (readelf -d) does it have before and after?

They are the same:

Dynamic section at offset 0x78090 contains 23 entries:
   Tag        Type                         Name/Value
  0x0000000000000001 (NEEDED)             Shared library: 
[libbfd-2.18.50.20071002.so]
  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
  0x000000000000000e (SONAME)             Library soname: 
[libopcodes-2.18.50.20071002.so]
  0x000000000000000f (RPATH)              Library rpath: 
[/work/builds/binutils/current/shared-build/opcodes/../bfd/.libs]
  0x000000000000000c (INIT)               0x25ae8
  0x000000000000000d (FINI)               0x2b2f8
  0x0000000000000004 (HASH)               0x158
  0x0000000000000005 (STRTAB)             0x850
  0x0000000000000006 (SYMTAB)             0x2e0
  0x000000000000000a (STRSZ)              695 (bytes)
  0x000000000000000b (SYMENT)             24 (bytes)
  0x0000000000000003 (PLTGOT)             0x178290
  0x0000000000000002 (PLTRELSZ)           360 (bytes)
  0x0000000000000014 (PLTREL)             RELA
  0x0000000000000017 (JMPREL)             0x25980
  0x0000000000000007 (RELA)               0xba0
  0x0000000000000008 (RELASZ)             151008 (bytes)
  0x0000000000000009 (RELAENT)            24 (bytes)
  0x000000006ffffffe (VERNEED)            0xb80
  0x000000006fffffff (VERNEEDNUM)         1
  0x000000006ffffff0 (VERSYM)             0xb08
  0x000000006ffffff9 (RELACOUNT)          6282
  0x0000000000000000 (NULL)               0x0

> But if it adds an rpath to the installed libraries, I think we should avoid that.

No, it does not do that. :-)

Cheers
   Nick

Re: compile failure due to undefined symbol

[Nick Clifton]

Hi Daniel,

>  0x000000000000000f (RPATH)              Library rpath: 
> [/work/builds/binutils/current/shared-build/opcodes/../bfd/.libs]

>> But if it adds an rpath to the installed libraries, I think we should 
>> avoid that.
> 
> No, it does not do that. :-)

Umm, make that, it does add an rpath.  Hmm, so why do the binaries still work 
if I rename my build bfd directory ?  I am confused:

   % cd shared-build
   % mv bfd bfd-tmp-rename
   % ldd ./install/bin/objdump
   libopcodes-2.18.50.20071002.so => 
/work/builds/binutils/current/shared-build/install/lib/libopcodes-2.18.50.20071002.so 
(0x0000002a95557000)
   libbfd-2.18.50.20071002.so => 
/work/builds/binutils/current/shared-build/install/lib/libbfd-2.18.50.20071002.so 
(0x0000002a956d1000)
   libc.so.6 => /lib64/tls/libc.so.6 (0x0000003d51f00000)
   /lib64/ld-linux-x86-64.so.2 (0x0000003d51d00000)

   % ldd ./install/lib/libopcodes.so
   libbfd-2.18.50.20071002.so => not found
   libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a956e6000)
   /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)

So the installed executables can find the installed libraries, but the 
installed libaries cannot find the other installed libraries.  Is this what 
should be expected ?

Cheers
   Nick

Re: compile failure due to undefined symbol

[Daniel Jacobowitz]

On Tue, Oct 02, 2007 at 04:08:08PM +0100, Nick Clifton wrote:
> Hi Daniel,
> 
> >  0x000000000000000f (RPATH)              Library rpath: 
> > [/work/builds/binutils/current/shared-build/opcodes/../bfd/.libs]
> 
> >> But if it adds an rpath to the installed libraries, I think we should avoid 
> >> that.
> > No, it does not do that. :-)
> 
> Umm, make that, it does add an rpath.  Hmm, so why do the binaries still work 
> if I rename my build bfd directory ?  I am confused:

If the RPATH directory is missing, it's ignored.  But if it's present,
it will be used - so putting some other libbfd there will break your
installed assembler and linker.  Potential security hole and definite
nuisance.

-- 
Daniel Jacobowitz
CodeSourcery

Re: compile failure due to undefined symbol

[Nick Clifton]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

Hi Daniel,

> If the RPATH directory is missing, it's ignored.  But if it's present,
> it will be used - so putting some other libbfd there will break your
> installed assembler and linker.  Potential security hole and definite
> nuisance.

Ah, understood.

OK, so the patch works just as well without the RPATH entry being added to the 
libopcodes library, so here is a revised version for people to ponder.

Cheers
   Nick



[-- Attachment #2: shared-libopcodes.patch --]
[-- Type: text/x-patch, Size: 3152 bytes --]

Index: opcodes/configure.in
===================================================================
RCS file: /cvs/src/src/opcodes/configure.in,v
retrieving revision 1.78
diff -c -3 -p -r1.78 configure.in
*** opcodes/configure.in	9 Sep 2007 01:22:57 -0000	1.78
--- opcodes/configure.in	2 Oct 2007 15:28:53 -0000
*************** AC_SUBST(cgendir)
*** 97,115 ****
  
  using_cgen=no
  
! # Horrible hacks to build DLLs on Windows.
! WIN32LDFLAGS=
! WIN32LIBADD=
! case "${host}" in
! *-*-cygwin*)
!   if test "$enable_shared" = "yes"; then
!     WIN32LDFLAGS="-no-undefined"
!     WIN32LIBADD="-L`pwd`/../bfd -lbfd -L`pwd`/../libiberty -liberty -L`pwd`/../intl -lintl -lcygwin"
!   fi
!   ;;
! esac
! AC_SUBST(WIN32LDFLAGS)
! AC_SUBST(WIN32LIBADD)
  
  # target-specific stuff:
  
--- 97,122 ----
  
  using_cgen=no
  
! # Horrible hacks to build DLLs on Windows and a shared library elsewhere.
! SHARED_LDFLAGS=
! SHARED_LIBADD=
! SHARED_DEPENDENCIES=
! if test "$enable_shared" = "yes"; then
!   case "${host}" in
!     *-*-cygwin*)
!       SHARED_LDFLAGS="-no-undefined"
!       SHARED_LIBADD="-L`pwd`/../bfd -lbfd -L`pwd`/../libiberty -liberty -L`pwd`/../intl -lintl -lcygwin"
!       ;;
!     *)
!       SHARED_LDFLAGS="-Wl,-z,defs"
!       SHARED_LIBADD="-Wl,`pwd`/../bfd/.libs/libbfd.so"
!       SHARED_DEPENDENCIES="`pwd`/../bfd/.libs/libbfd.so"
!       ;;
!   esac
! fi
! AC_SUBST(SHARED_LDFLAGS)
! AC_SUBST(SHARED_LIBADD)
! AC_SUBST(SHARED_DEPENDENCIES)
  
  # target-specific stuff:
  
Index: opcodes/Makefile.am
===================================================================
RCS file: /cvs/src/src/opcodes/Makefile.am,v
retrieving revision 1.121
diff -c -3 -p -r1.121 Makefile.am
*** opcodes/Makefile.am	14 Sep 2007 19:28:56 -0000	1.121
--- opcodes/Makefile.am	2 Oct 2007 15:28:53 -0000
*************** libopcodes_la_SOURCES =  dis-buf.c disas
*** 367,376 ****
  # Unfortunately this causes libtool to add -L$(libdir), referring to the
  # 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@
! libopcodes_la_LDFLAGS = -release `cat ../bfd/libtool-soversion` @WIN32LDFLAGS@
  
  # libtool will build .libs/libopcodes.a.  We create libopcodes.a in
  # the build directory so that we don't have to convert all the
--- 367,377 ----
  # Unfortunately this causes libtool to add -L$(libdir), referring to the
  # 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. So for building with shared libraries we use a
! # hardcoded path to libbfd.so instead of relying on the entries in libbfd.la.
! libopcodes_la_DEPENDENCIES = $(OFILES) @SHARED_DEPENDENCIES@
! libopcodes_la_LIBADD = $(OFILES) @SHARED_LIBADD@
! libopcodes_la_LDFLAGS = -release `cat ../bfd/libtool-soversion` @SHARED_LDFLAGS@
  
  # libtool will build .libs/libopcodes.a.  We create libopcodes.a in
  # the build directory so that we don't have to convert all the

Re: compile failure due to undefined symbol

[Daniel Jacobowitz]

On Tue, Oct 02, 2007 at 04:30:52PM +0100, Nick Clifton wrote:
> Hi Daniel,
> 
> > If the RPATH directory is missing, it's ignored.  But if it's present,
> > it will be used - so putting some other libbfd there will break your
> > installed assembler and linker.  Potential security hole and definite
> > nuisance.
> 
> Ah, understood.
> 
> OK, so the patch works just as well without the RPATH entry being added to the 
> libopcodes library, so here is a revised version for people to ponder.

Seems reasonable to me though I don't know about its portability (-Wl; -z).

-- 
Daniel Jacobowitz
CodeSourcery

Re: compile failure due to undefined symbol

[Nick Clifton]

Hi Daniel,

> Seems reasonable to me though I don't know about its portability (-Wl; -z).

Hmm, well that bit is not needed either.  I just put it in to make sure that 
the patch was working.  I will take it out now though.

Cheers
   Nick

Re: compile failure due to undefined symbol

[Maciej W. Rozycki]

On Tue, 2 Oct 2007, Nick Clifton wrote:

> OK, so the patch works just as well without the RPATH entry being added to the
> libopcodes library, so here is a revised version for people to ponder.
[...]
> !     *)
> !       SHARED_LDFLAGS="-Wl,-z,defs"
> !       SHARED_LIBADD="-Wl,`pwd`/../bfd/.libs/libbfd.so"
> !       SHARED_DEPENDENCIES="`pwd`/../bfd/.libs/libbfd.so"
> !       ;;

 Have you considered using "`pwd`/../bfd/libbfd.la" instead?  It should 
avoid much of the hassle, and for whoever's sake, people please do use 
libtool rather than trying to circumvent it!  It has been designed to 
handle such cases.  You do not even have to have it as a shared dependency 
-- putting "libbfd.la" permanently on the list of dependencies for 
libopcodes will just work, whether shared or archive and libtool will sort 
out all the boring details.

  Maciej

Re: compile failure due to undefined symbol

[Daniel Jacobowitz]

On Tue, Oct 02, 2007 at 04:02:17PM +0100, Nick Clifton wrote:
> Hi Daniel,
> 
> > What dynamic tags (readelf -d) does it have before and after?
> 
> They are the same:

I meant the installed library; is this that one?

>  0x000000000000000f (RPATH)              Library rpath: 
> [/work/builds/binutils/current/shared-build/opcodes/../bfd/.libs]

:-(

-- 
Daniel Jacobowitz
CodeSourcery

Re: compile failure due to undefined symbol

[Maciej W. Rozycki]

On Tue, 2 Oct 2007, Daniel Jacobowitz wrote:

> What dynamic tags (readelf -d) does it have before and after?  If your
> patch has no effect on the dynamic tags of installed libraries, then
> it's surely fine; it only affects running things from the build
> directory.  But if it adds an rpath to the installed libraries, I
> think we should avoid that.

 I have just noticed this thread, so no answers to specific bits, but some 
general notes.  Apparently we have some confusion in the tree about how 
libtool works.  I noticed it a few days ago quite spectacularly when 
trying to build cross-binutils.  I do build shared libraries for all 
configurations and in particular for cross-tools I skip archive libraries 
altogether.

 We have this RPATH_ENVVAR setting in the top-level directory.  It breaks 
things.  For my setup (Linux configurations) it adds some build 
directories to LD_LIBRARY_PATH.  It breaks system-installed tools when 
building a cross-toolchain, because the newly-built BFD library, although 
for the same host, has a different target.  But for a libtool-based setup 
there should be no need to use LD_LIBRARY_PATH or anything like this at 
all.  This is because libtool has explicit support for running uninstalled 
newly-built binaries via the "--mode=execute" option.  This option, under 
the bonnet, does all the relinking/rpath/whatever hassle is required for 
the given platform.  All that is required is that .la files are used to 
refer to libraries dependent on during the build and libtool.

 Of course there may be bugs in libtool, in particular in areas hardly 
anybody uses.  But the src/ tree is, I suppose, enough important a user of 
libtool that the maintainers would love to hear feedback from, be it good 
or critical.

 Likewise, all the installed binaries have RPATH set appropriately to 
reach odd locations libraries may be installed in, e.g.:

$ readelf -d /usr/bin/vax-linux-as | grep RPATH
 0x0000000f (RPATH)                      Library rpath: [/usr/i386-linux/vax-linux/lib]

There is no RPATH entry put into libraries themselves as I reckon it is 
not portable; I may be wrong here.  If opcodes depends on bfd, then the 
dependency should be recorded when linking the former -- libtools handles 
it automatically when it sees a .la file on the list of objects being 
linked together.

 Here is a patch I use to make cross-binutils build again, but obviously 
it only covers the problem and the actual fix is outlined above.

  Maciej

binutils-2.18-no-lib_path.patch
diff -up --recursive --new-file binutils-2.18.macro/Makefile.def binutils-2.18/Makefile.def
--- binutils-2.18.macro/Makefile.def	2007-08-06 20:00:27.000000000 +0000
+++ binutils-2.18/Makefile.def	2007-09-29 22:11:31.000000000 +0000
@@ -36,8 +36,8 @@ host_modules= { module= ash; };
 host_modules= { module= autoconf; };
 host_modules= { module= automake; };
 host_modules= { module= bash; };
-host_modules= { module= bfd; lib_path=.libs; bootstrap=true; };
-host_modules= { module= opcodes; lib_path=.libs; bootstrap=true; };
+host_modules= { module= bfd; bootstrap=true; };
+host_modules= { module= opcodes; bootstrap=true; };
 host_modules= { module= binutils; bootstrap=true; };
 host_modules= { module= bison; no_check_cross= true; };
 host_modules= { module= byacc; no_check_cross= true; };

Re: compile failure due to undefined symbol

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

On Tuesday 02 October 2007, Maciej W. Rozycki wrote:
>  We have this RPATH_ENVVAR setting in the top-level directory.  It breaks
> things.  For my setup (Linux configurations) it adds some build
> directories to LD_LIBRARY_PATH.  It breaks system-installed tools when
> building a cross-toolchain, because the newly-built BFD library, although
> for the same host, has a different target.  But for a libtool-based setup
> there should be no need to use LD_LIBRARY_PATH or anything like this at
> all.  This is because libtool has explicit support for running uninstalled
> newly-built binaries via the "--mode=execute" option.  This option, under
> the bonnet, does all the relinking/rpath/whatever hassle is required for
> the given platform.  All that is required is that .la files are used to
> refer to libraries dependent on during the build and libtool.

this is what we came to in a previous thread as well:
http://sourceware.org/ml/binutils/2007-07/msg00401.html

ive been simply deleting RPATH_ENVVAR in the toplevel configure for Gentoo ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]