libtool .la wierdness

[Jamie Lenehan <lenehan@twibble.org>]

Does someone knows how these libtool .la files are meant to work
and/or why they are the way they are.

When trying to link against libclamav I'm getting this:

  | if ccache i486-linux-gcc -DHAVE_CONFIG_H -I. -I/data/oe/build/wrap-glibc/tmp/work/p3scan-2.9.05d-r0/p3scan-2.9.05d/src -I..   -isystem/data/oe/build/wrap-glibc/tmp/staging/i486-linux/include -I/data/oe/build/wrap-glibc/tmp/staging/i486-linux/lib/../include -I/data/oe/build/wrap-glibc/tmp/staging/i486-linux/lib/../include  -isystem/data/oe/build/wrap-glibc/tmp/staging/i486-linux/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2 -MT restart.o -MD -MP -MF ".deps/restart.Tpo" -c -o restart.o restart.c; \
  |       then mv -f ".deps/restart.Tpo" ".deps/restart.Po"; else rm -f ".deps/restart.Tpo"; exit 1; fi
  | /bin/sh ../i486-linux-libtool --tag=CC --mode=link ccache i486-linux-gcc  -isystem/data/oe/build/wrap-glibc/tmp/staging/i486-linux/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2  -L/data/oe/build/wrap-glibc/tmp/staging/i486-linux/lib -Wl,-rpath-link,/data/oe/build/wrap-glibc/tmp/staging/i486-linux/lib -Wl,-O1 -L/data/oe/build/wrap-glibc/tmp/staging/i486-linux/lib/../lib -lclamav -L/data/oe/build/wrap-glibc/tmp/staging/i486-linux/lib/../lib -lssl -lcrypto -lpcre -o p3scan   p3scan.o getlinep3.o parsefile.o scanner_avpd.o scanner_avpd_new.o scanner_clamd.o scanner_trophie.o scanner_bash.o scanner_basic.o getline_ssl.o restart.o  -lpthread
  | mkdir .libs
  | i486-linux-libtool: link: cannot find the library /usr/lib/libz.la'
  | make[2]: *** [p3scan] Error 1
  | make[2]: Leaving directory /data/oe/build/wrap-glibc/tmp/work/p3scan-2.9.05d-r0/p3scan-2.9.05d/src'
  | make[1]: *** [all-recursive] Error 1
  | make[1]: Leaving directory /data/oe/build/wrap-glibc/tmp/work/p3scan-2.9.05d-r0/p3scan-2.9.05d'
  | make: *** [all] Error 2
  | FATAL: oe_runmake failed
  NOTE: Task failed: /data/oe/build/wrap-glibc/tmp/work/p3scan-2.9.05d-r0/temp/log.do_compile.6491
  NOTE: package p3scan-2.9.05d-r0: task do_compile: failed
  ERROR: TaskFailed event exception, aborting
  NOTE: package p3scan-2.9.05d: failed
  ERROR: Build of p3scan failed

This appears to be due to the obsolute path being to the libz .la
file being placed in the libclamav .la file:

  [nynaeve][ 5:24PM]/data/oe/build/wrap-glibc%> cat tmp/staging/i486-linux/lib/libclamav.la | grep dependency_libs
  dependency_libs=' -L/data/oe/build/wrap-glibc/tmp/staging/i486-linux/lib /usr/lib/libz.la -lbz2 /usr/lib/libgmp.la -lpthread -lnsl'

And it looks like it is doing this for any dependent libraries that
have a corresponding .la file themselves (see how libz and libgmp have
corresponding .la files):

  [nynaeve][ 5:24PM]/data/oe/build/wrap-glibc%> (cd tmp/staging/i486-linux/lib && ls libz* libbz* libgmp* libnsl*)
  libbz2.a      libbz2.so.1.0@    libgmp.la     libgmp.so.3.3.3*  libnsl.so@    libz.la     libz.so.1.2.3*
  libbz2.so@    libbz2.so.1.0.2*  libgmp.so@    libnsl-2.4.so*    libnsl.so.1@  libz.so@
  libbz2.so.1@  libgmp.a          libgmp.so.3@  libnsl.a          libz.a        libz.so.1@

If I modify the libclamav.la to be this:

  dependency_libs=' -L/data/oe/build/wrap-glibc/tmp/staging/i486-linux/lib -lz -lbz2 -lgmp -lpthread -lnsl'

then p3scan builds, links and runs fine. If I delete libclamav.la then p3scan
builds, links and runs fine.

If I remove the libz and libgmp .la files and then rebuild clamav you can
see the change in libclamav .la file:

  [nynaeve][ 5:25PM]/data/oe/build/wrap-glibc%> (cd tmp/staging/i486-linux/lib && rm libz.la libgmp.la)
  [nynaeve][ 5:26PM]/data/oe/build/wrap-glibc%> ./bb -b packages/clamav/clamav_0.88.4.bb -c clean
  ...
  [nynaeve][ 5:26PM]/data/oe/build/wrap-glibc%> ./bb -b packages/clamav/clamav_0.88.4.bb
  ...
  [nynaeve][ 5:27PM]/data/oe/build/wrap-glibc%> cat tmp/staging/i486-linux/lib/libclamav.la | grep dependency_libs
  dependency_libs=' -L/data/oe/build/wrap-glibc/tmp/staging/i486-linux/lib -lz -lbz2 -lgmp -lpthread -lnsl'
  [nynaeve][ 5:27PM]/data/oe/build/wrap-glibc%>

This look like a libtool problem to me, but libtool is one very confusing
tool. Should it be putting the "/usr/lib/libz.la" style references in the
.la files? Or should it know to look for those .la files elsewhere when
processing them? Or should we just do away with the .la files in staging
altogether?

-- 
 Jamie Lenehan <lenehan@twibble.org>