[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dan Kegel
Subject: .la file semantics? (was: [patch] make libtool1.4d work when cross-compiling)
Date: Sat, 09 Mar 2002 21:13:59 -0800

Dan Kegel wrote:
> The 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 file in the cross-compiler's library
  The .la file ends with the lines
    # Directory that this library needs to be installed in:

* 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="$libdir"            <==== this case fires, and sets dir to 

* 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.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]