Problems with using libtool dependencies in opcodes
Daniel Jacobowitz
drow@mvista.com
Mon Dec 22 18:23:00 GMT 2003
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?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
More information about the Binutils
mailing list