This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems with using libtool dependencies in opcodes


On Mon, Dec 22, 2003 at 01:21:04PM -0500, Daniel Jacobowitz wrote:
> This problem:
>   http://sources.redhat.com/ml/binutils/2003-06/msg00025.html
> is still present, and it's causing me a real headache.
> 
> I had hopes that the latest version of libtool would fix it, so I did a
> hack-job to get all of binutils using the new version and tried again.  What
> we used to get was a command like this (roughly):
> 
> gcc -shared  .libs/dis-buf.o .libs/disassemble.o .libs/dis-init.o \
>   .libs/i386-dis.o  -L/opt/src/binutils/inst-tmp/obj/libiberty/pic \
>   -Wl,--rpath -Wl,/usr/local/lib -L/usr/local/lib -lbfd \
>   -Wl,-soname -Wl,libopcodes-2.14.90.so -o .libs/libopcodes-2.14.90.so
> 
> 
> Now we get:
> 
> gcc -shared  .libs/dis-buf.o .libs/disassemble.o .libs/dis-init.o \
>   .libs/i386-dis.o  -L/opt/src/binutils/inst-tmp/obj/libiberty/pic \
>   -L/opt/src/binutils/inst-tmp/inst/usr/local/lib -L/usr/local/lib -lbfd \
>   -Wl,-soname -Wl,libopcodes-2.14.90.so -o .libs/libopcodes-2.14.90.so
> 
> That fixes the immediate problem but opens up a whole new can of worms.  By
> adding -L$libdir to the path, my cross compiler configuration starts trying
> to open /usr/lib/libc.so, which points it to /lib/libc.so.6.
> 
> This means that the patch to fix opcodes' listed dependencies (which is a
> legitimate problem, but AFAIK only causes real-world problems with
> prelinking) has caused all sorts of build regressions.  I think that the
> cure is worse than the problem.
> 
> Does anyone have any bright ideas for making libtool behave?  If not how do
> you feel about reverting:
> 
> 2003-05-17  Andreas Jaeger  <aj@suse.de>
> 
>         * Makefile.am (libopcodes_la_LIBADD): Add libbfd.la.
>         (libopcodes_la_DEPENDENCIES): Add libbfd.la.
>         * Makefile.in: Regenerated.
> 
> until someone comes up with a bright idea?  Am I forgetting another problem
> this patch solved?
> 

I have been using this patch.


H.J.
----
2003-05-23  H.J. Lu  <hongjiu.lu@intel.com>

	* ltmain.sh: Make symlink for shared library if needed.

opcodes/

2003-12-04  H.J. Lu  <hongjiu.lu@intel.com>

	* Makefile.in: Regenerated.

2003-09-03  H.J. Lu  <hongjiu.lu@intel.com>

	* Makefile.in: Regenerated.

2003-08-14  H.J. Lu  <hongjiu.lu@intel.com>

	* Makefile.in: Regenerated.

2003-07-14  H.J. Lu  <hongjiu.lu@intel.com>

	* Makefile.in: Regenerated.

2003-06-11  H.J. Lu  <hongjiu.lu@intel.com>

	* Makefile.in: Regenerated.

2003-05-23  H.J. Lu  <hongjiu.lu@intel.com>

	* Makefile.am (libopcodes_la_LIBADD): Use "-L../bfd -lbfd"
	instead of "../bfd/libbfd.la".
	* Makefile.in: Regenerated.

--- binutils/ltmain.sh.dso	2002-03-22 00:16:20.000000000 -0800
+++ binutils/ltmain.sh	2003-12-04 10:49:04.000000000 -0800
@@ -4413,6 +4413,10 @@ relink_command=\"$relink_command\""
       # LD_LIBRARY_PATH before the program is installed.
       $show "(cd $output_objdir && $rm $outputname && $LN_S ../$outputname $outputname)"
       $run eval '(cd $output_objdir && $rm $outputname && $LN_S ../$outputname $outputname)' || exit $?
+      if test -n "$linkname"; then
+        $show "(cd $output_objdir && $rm ../$linkname && $LN_S $output_objdir/$linkname ../$linkname)"
+        $run eval '(cd $output_objdir && $rm ../$linkname && $LN_S $output_objdir/$linkname ../$linkname)' || exit $?
+      fi
       ;;
     esac
     exit 0
--- binutils/opcodes/Makefile.am.dso	2003-12-04 10:43:28.000000000 -0800
+++ binutils/opcodes/Makefile.am	2003-12-04 10:49:04.000000000 -0800
@@ -284,7 +284,7 @@ disassemble.lo: disassemble.c $(INCDIR)/
 
 libopcodes_la_SOURCES =  dis-buf.c disassemble.c dis-init.c
 libopcodes_la_DEPENDENCIES = $(OFILES) ../bfd/libbfd.la
-libopcodes_la_LIBADD = $(OFILES) @WIN32LIBADD@ ../bfd/libbfd.la
+libopcodes_la_LIBADD = $(OFILES) @WIN32LIBADD@ -L../bfd -lbfd
 libopcodes_la_LDFLAGS = -release $(VERSION) @WIN32LDFLAGS@
 
 # libtool will build .libs/libopcodes.a.  We create libopcodes.a in
--- binutils/opcodes/Makefile.in.dso	2003-12-04 10:43:28.000000000 -0800
+++ binutils/opcodes/Makefile.in	2003-12-04 10:50:11.000000000 -0800
@@ -394,7 +394,7 @@ INCLUDES = -D_GNU_SOURCE -I. -I$(srcdir)
 
 libopcodes_la_SOURCES = dis-buf.c disassemble.c dis-init.c
 libopcodes_la_DEPENDENCIES = $(OFILES) ../bfd/libbfd.la
-libopcodes_la_LIBADD = $(OFILES) @WIN32LIBADD@ ../bfd/libbfd.la
+libopcodes_la_LIBADD = $(OFILES) @WIN32LIBADD@ -L../bfd -lbfd
 libopcodes_la_LDFLAGS = -release $(VERSION) @WIN32LDFLAGS@
 
 # libtool will build .libs/libopcodes.a.  We create libopcodes.a in
@@ -468,7 +468,7 @@ acinclude.m4 aclocal.m4 config.in config
 
 DISTFILES = $(DIST_COMMON) $(SOURCES) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST)
 
-TAR = tar
+TAR = gtar
 GZIP_ENV = --best
 SOURCES = libopcodes.a.c $(libopcodes_la_SOURCES)
 OBJECTS = libopcodes.a.$(OBJEXT) $(libopcodes_la_OBJECTS)
@@ -593,7 +593,7 @@ libopcodes.la: $(libopcodes_la_OBJECTS) 
 all-recursive install-data-recursive install-exec-recursive \
 installdirs-recursive install-recursive uninstall-recursive install-info-recursive \
 check-recursive installcheck-recursive info-recursive dvi-recursive:
-	@set fnord $(MAKEFLAGS); amf=$$2; \
+	@set fnord $$MAKEFLAGS; amf=$$2; \
 	dot_seen=no; \
 	target=`echo $@ | sed s/-recursive//`; \
 	list='$(SUBDIRS)'; for subdir in $$list; do \
@@ -613,7 +613,7 @@ check-recursive installcheck-recursive i
 
 mostlyclean-recursive clean-recursive distclean-recursive \
 maintainer-clean-recursive:
-	@set fnord $(MAKEFLAGS); amf=$$2; \
+	@set fnord $$MAKEFLAGS; amf=$$2; \
 	dot_seen=no; \
 	rev=''; list='$(SUBDIRS)'; for subdir in $$list; do \
 	  rev="$$subdir $$rev"; \


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]