libtool
[Top][All Lists]
Advanced

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

Re: "$to_tool_file_cmd" is empty


From: Gary V. Vaughan
Subject: Re: "$to_tool_file_cmd" is empty
Date: Wed, 24 Oct 2012 08:04:55 +0700

Hi Bruce,

Thanks for the report.

On Oct 24, 2012, at 12:44 AM, Bruce Korb <address@hidden> wrote:
>> lt-func_mode_compile> func_to_tool_file alloc.c func_convert_file_msys_to_w32

Are you building on some variant of Windows?

func_to_tool_file_command is set by _LT_PATH_CONVERSION_FUNCTIONS
from libtool.m4 at configure time, and can end up as a flavor of 
func_convert_file_*_to_w32
on mingw, func_convert_file_*_to_cygwin on cygwin, and in all other cases should
be func_convert_file_noop.

>> lt-func_to_tool_file> set -x
>> lt-func_to_tool_file> case ,$2, in
>> lt-func_to_tool_file> alloc.c
> ./libtool: line 2088: ./alloc.c: Permission denied
> 
> $ libtool --version|head -1
> libtool (GNU libtool) 2.4.2
> 
> #! /bin/sh
> 
> # libtool - Provide generalized library-building support services.
> # Generated automatically by config.status (gc) 7.3alpha3
> # Libtool was configured on host reml1006:
> # NOTE: Changes made to this file will be lost: look at ltmain.sh.
> #
> #   Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
> #                 2006, 2007, 2008, 2009, 2010 Free Software Foundation,
> #                 Inc.
> [.....]
> # func_to_tool_file ARG LAZY
> # converts the file name ARG from $build format to toolchain format. Return
> # result in func_to_tool_file_result.  If the conversion in use is listed
> # in (the comma separated) LAZY, no conversion takes place.
> func_to_tool_file ()
> {
>  $opt_debug
>  case ,$2, in
>    *,"$to_tool_file_cmd",*)
>      func_to_tool_file_result=$1
>      ;;
>    *)
> 
>      $to_tool_file_cmd "$1"  <<<<<===== "$to_tool_file_cmd" is empty
> ==============>>>>   neither ltmain.sh nor "libtool" contain an
> assignment to it.

ltmain.sh should not set it, 

>      func_to_tool_file_result=$func_to_host_file_result
>      ;;
>  esac
> }
> # end func_to_tool_file
> 
> 
> ====================================================
> 
> To make forward progress, I replaced $to_tool_file_cmd to
> ${to_tool_file_cmd:-noop_tool_file_cmd},
> but my build still did not finish:

There is no noop_tool_file_cmd, though unless you are on some flavour
of windows or cross-compiling, to_tool_file_cmd should be 
func_convert_file_noop.

What did configure output for the tests starting with:

  checking how to convert <??> filenames to <??> format... ???

What value was substituted into the following line in your Makefile:

  to_tool_file_cmd = ???

And similarly in your libtool script, where configure should also have
substituted the value it discovered in the tests above.

If your project is behaving weird, perhaps it is pulling in the wrong version
of libtool.m4 et. al? In that case, does everything above behave correctly
when you build a freshly unpacked libtool-2.4.2.tar.gz?  If it does then the
weirdness is in your project, if even libtool shows the wrong values, then
your environment is doing something to confuse configure...

None of this stuff has been changed since it was introduced in Sept 2010
according to ChangeLog, but then it is not really exercised on anything but
Windows, so it never comes into play on any of the machines I use --
except to always set it to func_convert_file_noop :)

Let me know if the hints above get you any closer to a solution, or if you
are still stuck.

> I give.  Too hard.

Windows makes me feel like that too ;)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)


reply via email to

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