.la file semantics? (was: [patch] make libtool1.4d work when cross-compiling)

[Dan Kegel]

Dan Kegel wrote:
> 
> The patch
>  http://www.kegel.com/libtool-cross-2.patch
> appears to fix libtool1.4d so it sets sys_lib_search_path_spec properly,
> which is probably required for cross-compiling programs that use libtool.
> 
> To test it, I created dummy cross-compiler mycc ...

Unfortunately, when I tested it with a real cross-compiler, I found
that it did not solve the problem.  

It looks like there is some confusion about
whether the 'libdir' line of the .la file is to be interpreted at
compile time or at run time.  If it's supposed to be compile-time only,
then my .la file is wrong.  If it's supposed to be run-time only, libtool
is buggy.  If it's supposed to be valid both at run-time and at compile-time,
we have a real problem :-)

Can any libtool experts point me to the documentation for the .la file format?

Here's what happened when I linked a program that uses -lbfd:

* libtool correctly found the libbfd.la file in the cross-compiler's library
  The .la file ends with the lines
    # Directory that this library needs to be installed in:
    libdir='/usr/lib'

* libtool sources the .la file,  setting libdir to /usr/lib
   This is fine, since the library really will be installed in /usr/lib.

* libtool then mucks around for a while, then hits this code:
        # Find the relevant object directory and library name.
        if test "X$installed" = Xyes; then
          if test ! -f "$libdir/$linklib" && test -f "$abs_ladir/$linklib"; then
            $echo "$modename: warning: library \`$lib' was moved." 1>&2
            dir="$ladir"
            absdir="$abs_ladir"
            libdir="$abs_ladir"
          else
            dir="$libdir"            <==== this case fires, and sets dir to 
/usr/lib
            absdir="$libdir"

* libtool continues a bit, then hits this code:

        elif test "$linkmode" = prog; then
          # Here we assume that one of hardcode_direct or hardcode_minus_L
          # is not unsupported.  This is valid on all known static and
          # shared platforms.
          if test "$hardcode_direct" != unsupported; then
            test -n "$old_library" && linklib="$old_library"
            compile_deplibs="$dir/$linklib $compile_deplibs"
            finalize_deplibs="$dir/$linklib $finalize_deplibs"
              <===== This case fires, and sets compile_deplibs to 
"/usr/lib/libbfd.a -lm"

* This caused libtool to incorrectly turn -lbfd into /usr/lib/libbfd.a.

I found the code quite difficult to trace through.  (I wish bash had
a 'log line number' option; maybe I should add one.)

Thanks,
Dan