Re: Problems with using libtool dependencies in opcodes

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Jan 03, 2004 at 09:51:45PM +0100, Andreas Jaeger wrote:
> Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > 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?
> >
> > Unless someone can give me a reason that this patch is necessary, I
> > plan to revert it next week, with appropriate commentary.
> 
> What exactly from my message explaining the patch is not clear?
> 
> http://sources.redhat.com/ml/binutils/2003-05/msg00424.html
> 
> libopcodes.so using functionality from libbfd.so and therefore we need
> to add a DL_NEEDED reference in libopcodes.so to give:
> $ ldd /usr/lib/libopcodes.so 
>         libbfd-2.14.90.0.5.so => /usr/lib/libbfd-2.14.90.0.5.so (0x4002c000)
>         libc.so.6 => /lib/i686/libc.so.6 (0x400c8000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

That's precisely the reason I'm prepared to ignore.  I wanted to make
sure that it didn't also cause a runtime failure in the binutils for
some reason.

I am forced to consider build regressions more important than easily
avoidable or harmless runtime problems and no one has demonstrated a
fix for the libtool problem this patch uncovered.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer