* compile failure due to undefined symbol
@ 2007-08-31 13:42 Peter S. Mazinger
2007-09-01 0:17 ` Alan Modra
0 siblings, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-08-31 13:42 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-08-31 13:42 compile failure due to undefined symbol Peter S. Mazinger
@ 2007-09-01 0:17 ` Alan Modra
2007-09-01 0:47 ` Peter S. Mazinger
0 siblings, 1 reply; 32+ messages in thread
From: Alan Modra @ 2007-09-01 0:17 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-09-01 0:17 ` Alan Modra
@ 2007-09-01 0:47 ` Peter S. Mazinger
2007-09-28 8:56 ` Nick Clifton
0 siblings, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-09-01 0:47 UTC (permalink / raw)
To: Alan Modra; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-09-01 0:47 ` Peter S. Mazinger
@ 2007-09-28 8:56 ` Nick Clifton
2007-09-28 12:23 ` Peter S. Mazinger
0 siblings, 1 reply; 32+ messages in thread
From: Nick Clifton @ 2007-09-28 8:56 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: Alan Modra, binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-09-28 8:56 ` Nick Clifton
@ 2007-09-28 12:23 ` Peter S. Mazinger
2007-09-28 12:55 ` Nick Clifton
0 siblings, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-09-28 12:23 UTC (permalink / raw)
To: Nick Clifton; +Cc: Alan Modra, binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-09-28 12:23 ` Peter S. Mazinger
@ 2007-09-28 12:55 ` Nick Clifton
2007-09-28 13:48 ` Peter S. Mazinger
0 siblings, 1 reply; 32+ messages in thread
From: Nick Clifton @ 2007-09-28 12:55 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: Alan Modra, binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-09-28 12:55 ` Nick Clifton
@ 2007-09-28 13:48 ` Peter S. Mazinger
2007-10-02 11:05 ` Nick Clifton
0 siblings, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-09-28 13:48 UTC (permalink / raw)
To: Nick Clifton; +Cc: Alan Modra, binutils
[-- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-09-28 13:48 ` Peter S. Mazinger
@ 2007-10-02 11:05 ` Nick Clifton
2007-10-02 13:13 ` Peter S. Mazinger
2007-10-02 14:23 ` Daniel Jacobowitz
0 siblings, 2 replies; 32+ messages in thread
From: Nick Clifton @ 2007-10-02 11:05 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: Alan Modra, binutils
[-- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 11:05 ` Nick Clifton
@ 2007-10-02 13:13 ` Peter S. Mazinger
2007-10-03 11:06 ` Peter S. Mazinger
2007-10-02 14:23 ` Daniel Jacobowitz
1 sibling, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-10-02 13:13 UTC (permalink / raw)
To: Nick Clifton; +Cc: Alan Modra, binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 11:05 ` Nick Clifton
2007-10-02 13:13 ` Peter S. Mazinger
@ 2007-10-02 14:23 ` Daniel Jacobowitz
2007-10-02 14:41 ` Nick Clifton
1 sibling, 1 reply; 32+ messages in thread
From: Daniel Jacobowitz @ 2007-10-02 14:23 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 14:23 ` Daniel Jacobowitz
@ 2007-10-02 14:41 ` Nick Clifton
2007-10-02 15:01 ` Daniel Jacobowitz
0 siblings, 1 reply; 32+ messages in thread
From: Nick Clifton @ 2007-10-02 14:41 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 14:41 ` Nick Clifton
@ 2007-10-02 15:01 ` Daniel Jacobowitz
2007-10-02 15:07 ` Nick Clifton
2007-10-02 15:41 ` Maciej W. Rozycki
0 siblings, 2 replies; 32+ messages in thread
From: Daniel Jacobowitz @ 2007-10-02 15:01 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 15:01 ` Daniel Jacobowitz
@ 2007-10-02 15:07 ` Nick Clifton
2007-10-02 15:07 ` Nick Clifton
2007-10-02 15:13 ` Daniel Jacobowitz
2007-10-02 15:41 ` Maciej W. Rozycki
1 sibling, 2 replies; 32+ messages in thread
From: Nick Clifton @ 2007-10-02 15:07 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 15:07 ` Nick Clifton
@ 2007-10-02 15:07 ` Nick Clifton
2007-10-02 15:30 ` Daniel Jacobowitz
2007-10-02 15:13 ` Daniel Jacobowitz
1 sibling, 1 reply; 32+ messages in thread
From: Nick Clifton @ 2007-10-02 15:07 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 15:07 ` Nick Clifton
2007-10-02 15:07 ` Nick Clifton
@ 2007-10-02 15:13 ` Daniel Jacobowitz
1 sibling, 0 replies; 32+ messages in thread
From: Daniel Jacobowitz @ 2007-10-02 15:13 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 15:07 ` Nick Clifton
@ 2007-10-02 15:30 ` Daniel Jacobowitz
2007-10-02 15:35 ` Nick Clifton
0 siblings, 1 reply; 32+ messages in thread
From: Daniel Jacobowitz @ 2007-10-02 15:30 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 15:30 ` Daniel Jacobowitz
@ 2007-10-02 15:35 ` Nick Clifton
2007-10-02 15:36 ` Daniel Jacobowitz
2007-10-02 17:52 ` Maciej W. Rozycki
0 siblings, 2 replies; 32+ messages in thread
From: Nick Clifton @ 2007-10-02 15:35 UTC (permalink / raw)
To: binutils
[-- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 15:35 ` Nick Clifton
@ 2007-10-02 15:36 ` Daniel Jacobowitz
2007-10-02 15:51 ` Nick Clifton
2007-10-02 17:52 ` Maciej W. Rozycki
1 sibling, 1 reply; 32+ messages in thread
From: Daniel Jacobowitz @ 2007-10-02 15:36 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 15:01 ` Daniel Jacobowitz
2007-10-02 15:07 ` Nick Clifton
@ 2007-10-02 15:41 ` Maciej W. Rozycki
2007-10-02 20:49 ` Mike Frysinger
1 sibling, 1 reply; 32+ messages in thread
From: Maciej W. Rozycki @ 2007-10-02 15:41 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: binutils
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; };
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 15:36 ` Daniel Jacobowitz
@ 2007-10-02 15:51 ` Nick Clifton
0 siblings, 0 replies; 32+ messages in thread
From: Nick Clifton @ 2007-10-02 15:51 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 15:35 ` Nick Clifton
2007-10-02 15:36 ` Daniel Jacobowitz
@ 2007-10-02 17:52 ` Maciej W. Rozycki
1 sibling, 0 replies; 32+ messages in thread
From: Maciej W. Rozycki @ 2007-10-02 17:52 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 15:41 ` Maciej W. Rozycki
@ 2007-10-02 20:49 ` Mike Frysinger
0 siblings, 0 replies; 32+ messages in thread
From: Mike Frysinger @ 2007-10-02 20:49 UTC (permalink / raw)
To: binutils; +Cc: Maciej W. Rozycki, Daniel Jacobowitz
[-- 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 --]
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-02 13:13 ` Peter S. Mazinger
@ 2007-10-03 11:06 ` Peter S. Mazinger
2007-10-04 14:13 ` Nick Clifton
0 siblings, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-10-03 11:06 UTC (permalink / raw)
To: Nick Clifton; +Cc: Alan Modra, binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-03 11:06 ` Peter S. Mazinger
@ 2007-10-04 14:13 ` Nick Clifton
2007-10-04 15:02 ` Peter S. Mazinger
0 siblings, 1 reply; 32+ messages in thread
From: Nick Clifton @ 2007-10-04 14:13 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils
[-- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-04 14:13 ` Nick Clifton
@ 2007-10-04 15:02 ` Peter S. Mazinger
2007-10-04 16:26 ` Nick Clifton
0 siblings, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-10-04 15:02 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-04 15:02 ` Peter S. Mazinger
@ 2007-10-04 16:26 ` Nick Clifton
2007-10-04 21:01 ` Peter S. Mazinger
0 siblings, 1 reply; 32+ messages in thread
From: Nick Clifton @ 2007-10-04 16:26 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-04 16:26 ` Nick Clifton
@ 2007-10-04 21:01 ` Peter S. Mazinger
2007-10-05 9:02 ` Peter S. Mazinger
0 siblings, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-10-04 21:01 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-04 21:01 ` Peter S. Mazinger
@ 2007-10-05 9:02 ` Peter S. Mazinger
2007-10-08 10:45 ` Nick Clifton
0 siblings, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-10-05 9:02 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-05 9:02 ` Peter S. Mazinger
@ 2007-10-08 10:45 ` Nick Clifton
2007-10-08 13:41 ` Peter S. Mazinger
0 siblings, 1 reply; 32+ messages in thread
From: Nick Clifton @ 2007-10-08 10:45 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils
[-- 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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-08 10:45 ` Nick Clifton
@ 2007-10-08 13:41 ` Peter S. Mazinger
2007-10-08 13:51 ` Peter S. Mazinger
0 siblings, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-10-08 13:41 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-08 13:41 ` Peter S. Mazinger
@ 2007-10-08 13:51 ` Peter S. Mazinger
2007-10-08 17:55 ` Nick Clifton
0 siblings, 1 reply; 32+ messages in thread
From: Peter S. Mazinger @ 2007-10-08 13:51 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: compile failure due to undefined symbol
2007-10-08 13:51 ` Peter S. Mazinger
@ 2007-10-08 17:55 ` Nick Clifton
0 siblings, 0 replies; 32+ messages in thread
From: Nick Clifton @ 2007-10-08 17:55 UTC (permalink / raw)
To: Peter S. Mazinger; +Cc: binutils
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
^ permalink raw reply [flat|nested] 32+ messages in thread
end of thread, other threads:[~2007-10-08 15:41 UTC | newest]
Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-08-31 13:42 compile failure due to undefined symbol Peter S. Mazinger
2007-09-01 0:17 ` Alan Modra
2007-09-01 0:47 ` Peter S. Mazinger
2007-09-28 8:56 ` Nick Clifton
2007-09-28 12:23 ` Peter S. Mazinger
2007-09-28 12:55 ` Nick Clifton
2007-09-28 13:48 ` Peter S. Mazinger
2007-10-02 11:05 ` Nick Clifton
2007-10-02 13:13 ` Peter S. Mazinger
2007-10-03 11:06 ` Peter S. Mazinger
2007-10-04 14:13 ` Nick Clifton
2007-10-04 15:02 ` Peter S. Mazinger
2007-10-04 16:26 ` Nick Clifton
2007-10-04 21:01 ` Peter S. Mazinger
2007-10-05 9:02 ` Peter S. Mazinger
2007-10-08 10:45 ` Nick Clifton
2007-10-08 13:41 ` Peter S. Mazinger
2007-10-08 13:51 ` Peter S. Mazinger
2007-10-08 17:55 ` Nick Clifton
2007-10-02 14:23 ` Daniel Jacobowitz
2007-10-02 14:41 ` Nick Clifton
2007-10-02 15:01 ` Daniel Jacobowitz
2007-10-02 15:07 ` Nick Clifton
2007-10-02 15:07 ` Nick Clifton
2007-10-02 15:30 ` Daniel Jacobowitz
2007-10-02 15:35 ` Nick Clifton
2007-10-02 15:36 ` Daniel Jacobowitz
2007-10-02 15:51 ` Nick Clifton
2007-10-02 17:52 ` Maciej W. Rozycki
2007-10-02 15:13 ` Daniel Jacobowitz
2007-10-02 15:41 ` Maciej W. Rozycki
2007-10-02 20:49 ` Mike Frysinger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).