[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "$to_tool_file_cmd" is empty
From: |
Bruce Korb |
Subject: |
Re: "$to_tool_file_cmd" is empty |
Date: |
Wed, 24 Oct 2012 05:22:17 -0700 |
Hi Gary,
On Tue, Oct 23, 2012 at 6:04 PM, Gary V. Vaughan <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?
OS/X Lion.
>> $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,
Whatever was supposed to set it, didn't. I found three references to it in
libtoos/ltmain.sh, but they were all using its value and not setting it.
>> 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
I didn't know about func_convert_file_noop, so I wrote my own equivalent.
> 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 = ???
It would then have to be exported to the libtool script environment.
Clearly, it was not. I'll answer these in a couple of hours (when I
get to work where the system at issue is.)
> And similarly in your libtool script, where configure should also have
> substituted the value it discovered in the tests above.
There was no assignment to "to_tool_file_cmd" anywhere in the script.
> If your project is behaving weird,
It is a project required by a project required by guile required by my toy.
I haven't been able to get fink to work behind a fire wall using either
rsync or ftp protocols. In the effort to make fink up-to-the-second current,
they've made it inaccessible to folks locked behind a protective fire wall.
> perhaps it is pulling in the wrong version
> of libtool.m4 et. al?
I'm running a bootstrap script using the latest releases of
autoconf/automake/libtool.
> 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...
Probably, but I have no idea where it turns south.
> 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 ;)
OS/X. :(
Thank you. Cheers - Bruce
P.S. Were you able to help Mark Weaver with: user_search_path vs
libtool --mode=execute -dlopen ?
I'm holding on to the next release until I know what Guile is going to
do about fiddling LD_LIBRARY_PATH.