[arch-general] ../libtool: line 2083: ark_part.cpp: command not found?
Guys, I need help, or a link, to find out why libtool isn't working. libtool is attempting to use an undeclared variable as a command. The libtool file generated includes (beginning at line 2071): # 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" func_to_tool_file_result=$func_to_host_file_result ;; esac } # end func_to_tool_file The tdeutils build fails at make on the very first file (ark_part.cpp). The line that fails is line 2083: 2083| $to_tool_file_cmd "$1" The problem is '$to_tool_file_cmd' is never declared in 'libtool' resulting in the error: ../libtool: line 2083: ark_part.cpp: command not found Basically, libtool is trying to execute 'ark_part.cpp' as the command since '$to_tool_file_cmd' is never declared or initialized and is just blank in the command '$to_tool_file_cmd "$1"'. What I need to learn is whether this is a libtool problem or whether it is a tdeutils problem. tdeutils from the same source builds fine on slack, debian, etc.., so I wonder if this is a libtool version problem or something similar. I am building in an arch chroot and he PKGBUILD file used does: cd ${srcdir}/${pkgname#*-} cp /usr/share/aclocal/libtool.m4 ./admin cp /usr/share/libtool/config/ltmain.sh ./admin make -f admin/Makefile.common ./configure \ --prefix=${TDEDIR} \ --with-qt-dir=${QTDIR} \ --sysconfdir=/etc \ --localstatedir=/var \ --enable-debug=full \ --enable-closure make The complete error, which I don't fully understand is: /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE64_SOURCE -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -fno-builtin -g3 -fno-inline -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -MT ark_part.lo -MD -MP -MF .deps/ark_part.Tpo -c -o ark_part.lo ark_part.cpp ../libtool: line 2083: ark_part.cpp: command not found I have also tried 'make SHELL=/bin/bash' after googling that the environment could cause shell extension issues if part was done with bash and make was using sh, but that made no difference. Anybody familiar with libtool know if this is a libtool problem or if this is a problem with the tdeutil code? If it is libtool, any work-arounds? -- David C. Rankin, J.D.,P.E.
On 03/19/2012 10:42 AM, David C. Rankin wrote:
Guys,
I need help, or a link, to find out why libtool isn't working. libtool is attempting to use an undeclared variable as a command. The libtool file generated includes (beginning at line 2071):
# 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" func_to_tool_file_result=$func_to_host_file_result ;; esac } # end func_to_tool_file
The tdeutils build fails at make on the very first file (ark_part.cpp). The line that fails is line 2083:
2083| $to_tool_file_cmd "$1"
The problem is '$to_tool_file_cmd' is never declared in 'libtool' resulting in the error:
../libtool: line 2083: ark_part.cpp: command not found
<snip> I think that I have found the crux of the issue at the very end of libtool.m4. That is where to_tool_file_cmd is supposedly set: AC_MSG_CHECKING([how to convert $build file names to toolchain format]) AC_CACHE_VAL(lt_cv_to_tool_file_cmd, [#assume ordinary cross tools, or native build. lt_cv_to_tool_file_cmd=func_convert_file_noop case $host in *-*-mingw* ) case $build in *-*-mingw* ) # actually msys lt_cv_to_tool_file_cmd=func_convert_file_msys_to_w32 ;; esac ;; esac ]) to_tool_file_cmd=$lt_cv_to_tool_file_cmd ^^^^^^^^^^^^^^^^ AC_MSG_RESULT([$lt_cv_to_tool_file_cmd]) _LT_DECL([to_tool_file_cmd], [lt_cv_to_tool_file_cmd], [0], [convert $build files to toolchain format])dnl ])# _LT_PATH_CONVERSION_FUNCTIONS This is a direct copy of the arch libtool.m4 file into the admin directory of tdeutils. I still don't know whether this is a libtool bug or if it is a tdeutils issues - anybody have a guess? I'll post to the tde list as well. Thanks. -- David C. Rankin, J.D.,P.E.
On ma, 2012-03-19 at 10:42 -0500, David C. Rankin wrote:
Anybody familiar with libtool know if this is a libtool problem or if this is a problem with the tdeutil code? If it is libtool, any work-arounds?
Either you're missing a command, or more likely, the fork of libtool included in the source differs from the libtool version on your system. Running "libtoolize --force", followed by all the autofoo afterwards, would solve your problem I guess.
On 03/19/2012 11:20 AM, Jan de Groot wrote:
On ma, 2012-03-19 at 10:42 -0500, David C. Rankin wrote:
Anybody familiar with libtool know if this is a libtool problem or if this is a problem with the tdeutil code? If it is libtool, any work-arounds?
Either you're missing a command, or more likely, the fork of libtool included in the source differs from the libtool version on your system. Running "libtoolize --force", followed by all the autofoo afterwards, would solve your problem I guess.
Jan, You are correct. The whole problem is that the libtool 2.4.2-4 in Arch includes parsing functions like to_tool_file_cmd that are not used in the trinity libtool version. The strange part is that libtool and autoreconf fail to recognize this even with --force and include the parsing functions in the file setup. This fails when those variables are not initialized. It almost seems like a bug that autoXYZ wouldn't catch the fact that it is using uninitialized variables. Do you know any way to just tell libtool or autoXYZ to just turn the toolchain parsing stuff off? I know nothing about the libtool/auto... world except it works when it works. I'll keep looking to see if I can find this being handled anywhere else, but if you, or anyone, have any idea how to work around this issue, I would welcome your thoughts. -- David C. Rankin, J.D.,P.E.
participants (2)
-
David C. Rankin
-
Jan de Groot