Re: "$to_tool_file_cmd" is empty
Hi Gary,
On Tue, Oct 23, 2012 at 6:04 PM, Gary V. Vaughan 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.
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: "$to_tool_file_cmd" is empty
Here ya go. The full log of the "autogen.sh" run, the configure and the build.
The project is "bdwgc", whatever that is.
$ bash -x ./autogen.sh
>sh> export 'PS4=>sh-${FUNCNAME}> '
>sh> PS4='>sh-${FUNCNAME}> '
>sh-> do_always
>sh-do_always> export 'PS1=\w\n\$ '
>sh-do_always> PS1='\w\n\$ '
>sh-do_always> case "$-" in
>sh-do_always> setx='set -x'
>sh-do_always> export LOGINLOG=/tmp/LOGIN
>sh-do_always> LOGINLOG=/tmp/LOGIN
>sh-do_always> export setx
>sh-do_always> export 'unsetx=set +x'
>sh-do_always> unsetx='set +x'
>sh-do_always> export shload_mode=hxB
>sh-do_always> shload_mode=hxB
>sh-do_always>
>PATH='/Users/bruce/bin:/opt/local/bin:/opt/local/sbin:.:/Users/bruce/bin:/usr/local/bin:/usr/local/git/bin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/usr/X11R6/bin:/Library/Application
> Support/VMware Fusion'
>sh-do_always> exec
>sh-do_always> BASH_XTRACEFD=8
>sh-do_always> printf '\n\n'
>sh-do_always> set -x
>>sh-do_always> date
>sh-do_always> : /Users/bruce/.bashrc begin Wed Oct 24 06:54:46 PDT 2012
>sh-do_always> for f in '/usr/local/lib/bash/*'
>sh-do_always> case "$(exec 2>/dev/null;file $f)" in
>>sh-do_always> exec
>sh-> test 4 -eq 0
>sh-> case ${shload_mode} in
>sh-> do_non_interact
>sh-do_non_interact> interactive=false
>sh-do_non_interact> shopt extglob expand_aliases
>sh-> export interactive TMPDIR=/tmp 'PS4=>${FUNCNAME:-sh}> '
>sh-> TMPDIR=/tmp
>sh-> PS4='>${FUNCNAME:-sh}> '
>sh> umask 022
>sh> unset VERBOSE
>sh> unset -f init_hosts do_always do_interactive do_non_interact do_always
>sh> readonly hostinits_done
>sh> set -e
>sh> autoreconf -i
configure.ac:605: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
body
../../../lib/autoconf/lang.m4:197: AC_LANG_CONFTEST is expanded from...
../../../lib/autoconf/general.m4:2670: _AC_LINK_IFELSE is expanded from...
../../../lib/autoconf/general.m4:2680: AC_LINK_IFELSE is expanded from...
m4/libtool.m4:1100: _LT_SYS_MODULE_PATH_AIX is expanded from...
m4/libtool.m4:5331: _LT_LINKER_SHLIBS is expanded from...
m4/libtool.m4:5416: _LT_LANG_C_CONFIG is expanded from...
m4/libtool.m4:240: _LT_SETUP is expanded from...
m4/libtool.m4:104: LT_INIT is expanded from...
m4/libtool.m4:107: AC_PROG_LIBTOOL is expanded from...
configure.ac:605: the top level
configure.ac:605: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
body
../../../lib/autoconf/lang.m4:197: AC_LANG_CONFTEST is expanded from...
../../../lib/autoconf/general.m4:2670: _AC_LINK_IFELSE is expanded from...
../../../lib/autoconf/general.m4:2680: AC_LINK_IFELSE is expanded from...
m4/libtool.m4:5331: _LT_LINKER_SHLIBS is expanded from...
m4/libtool.m4:5416: _LT_LANG_C_CONFIG is expanded from...
m4/libtool.m4:240: _LT_SETUP is expanded from...
m4/libtool.m4:104: LT_INIT is expanded from...
m4/libtool.m4:107: AC_PROG_LIBTOOL is expanded from...
configure.ac:605: the top level
configure.ac:605: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
body
../../../lib/autoconf/lang.m4:197: AC_LANG_CONFTEST is expanded from...
../../../lib/autoconf/general.m4:2670: _AC_LINK_IFELSE is expanded from...
../../../lib/autoconf/general.m4:2680: AC_LINK_IFELSE is expanded from...
m4/libtool.m4:1100: _LT_SYS_MODULE_PATH_AIX is expanded from...
m4/libtool.m4:6443: _LT_LANG_CXX_CONFIG is expanded from...
m4/libtool.m4:822: _LT_LANG is expanded from...
m4/libtool.m4:811: LT_LANG is expanded from...
m4/libtool.m4:858: _LT_LANG_DEFAULT_CONFIG is expanded from...
m4/libtool.m4:240: _LT_SETUP is expanded from...
m4/libtool.m4:104: LT_INIT is expanded from...
m4/libtool.m4:107: AC_PROG_LIBTOOL is expanded from...
configure.ac:605: the top level
configure.ac:605: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
body
../../../lib/autoconf/lang.m4:197: AC_LANG_CONFTEST is expanded from...
../../../lib/autoconf/general.m4:2670: _AC_LINK_IFELSE is expanded from...
../../../lib/autoconf/general.m4:2680: AC_LINK_IFELSE is expanded from...
m4/libtool.m4:1100: _LT_SYS_MODULE_PATH_AIX is expanded from...
m4/libtool.m4:5331: _LT_LINKER_SHLIBS is expanded from...
m4/libtool.m4:5416: _LT_LANG_C_CONFIG is expanded from...
m4/libtool.m4:240: _LT_SETUP is expanded from...
m4/libtool.m4:104: LT_INIT is expanded from...
m4/libtool.m4:107: AC_PROG_LIBTOOL is expanded from...
configure.ac:605: the top level
configure.ac:605: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
body
../../../lib/autoconf/lang.m4:197: AC_LANG_CONFTEST is expanded from...
../../../lib/autoconf/general.m4:2670: _AC_LINK_IFELSE is expanded from...
../../../lib/autoconf/general.m4:2680: AC_LINK_IFELSE is expanded from...
m4/libtool.m4:5331: _LT_LINKER_SHLIBS is expanded from...
m4/libtool.m4:5416: _LT_LANG_C_CONFIG is expanded from...
m4/libtool.m4:240: _LT_SETUP is expanded from...
m4/libtool.m4:104: LT_INIT is expanded from...
m4/libtool.m4:107: AC_PROG_LIBTOOL is expanded from...
configure.ac:605: the top level
configure.ac:605: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in
Re: "$to_tool_file_cmd" is empty
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. ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: "$to_tool_file_cmd" is empty
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 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) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: "$to_tool_file_cmd" is empty
Hi Bruce, On 24 Oct 2012, at 19:22, Bruce Korb wrote: > 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. That seems to have fallen off my radar. I don't recall having done anything in that regard. Feel free to jog my memory. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org) ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: "$to_tool_file_cmd" is empty
On Wed, Oct 24, 2012 at 7:22 AM, Gary V. Vaughan wrote: > Hi Bruce, > > On 24 Oct 2012, at 19:22, Bruce Korb wrote: >> 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. > > That seems to have fallen off my radar. I don't recall having done > anything in that regard. Feel free to jog my memory. http://www.mail-archive.com/libtool@gnu.org/msg13034.html ___ https://lists.gnu.org/mailman/listinfo/libtool
