Re: "$to_tool_file_cmd" is empty

[Gary V. Vaughan]

Hi Bruce,

Looking at your log, _LT_PATH_CONVERSION_FUNCTIONS is never run because
the configure output doesn't even show the selection of func_to_tool_file_cmd
from the check it expands to.  This is likely induced by the swathe of
autoconf warnings when you try to rebuild configure, leaving you with a stale
configure not updated with the macro expansions required to match
the ltmain.sh used to generate libtool.

On 24 Oct 2012, at 21:05, Bruce Korb <address@hidden> wrote:
> P.S.:
> 
> $ fgrep to_tool_file_cmd *
> libtool:    *,"$to_tool_file_cmd",*)
> libtool:      $to_tool_file_cmd "$1"
> libtool:            case $nm_file_list_spec~$to_tool_file_cmd in
> ltmain.sh:    *,"$to_tool_file_cmd",*)
> ltmain.sh:      $to_tool_file_cmd "$1"
> ltmain.sh:          case $nm_file_list_spec~$to_tool_file_cmd in
> 
> There is no assignment to to_tool_file_cmd anywhere.

It should have been injected into the libtool script, by config.status,
which in turn is supposed to contain the expansion of 
_LT_PATH_CONVERSION_FUNCTIONS.

Let's step back a little here.

On my Mac 10.7.5 Lion box, I have Apple's m4 1.4.16, and Automake 1.12.4
and Autoconnf 2.69 from Homebrew (Homebrew is much saner than fink, you
should consider migrating).  From there I can build libtool-2.4.2 from the
release tarball, and libtool master from git, and get a successful distcheck.

If you can do that, then I think it confirms my hypothesis that your
configure.ac is malformed and thus does not generate a full and proper
configure script with the necessary magic in it to get a working libtool.
You might be able to limp along using the install glib tool script from
Homebrew if your configure is not too brain-damaged by the lack of proper
regeneration...

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