By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 924 - libtool version in GIT causes build failures with current stable libtool version
Summary: libtool version in GIT causes build failures with current stable libtool version
Status: RESOLVED INVALID
Alias: None
Product: TDE
Classification: Unclassified
Component: tdeutils (show other bugs)
Version: R14.0.0 [Trinity]
Hardware: All Linux
: P5 blocker
Assignee: Timothy Pearson
URL:
Depends on:
Blocks:
 
Reported: 2012-03-21 14:32 CDT by David C. Rankin
Modified: 2012-10-19 15:28 CDT (History)
2 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David C. Rankin 2012-03-21 14:32:41 CDT 
When using system libtool version 2.4.2 (current stable release) to build tdeutils, the libtool executable generate by ./configure in the tdeutils directory fails to declare or initialize 'to_tool_file_cmd' within the libtool executable resulting in a build failure of every file. This may apply to all other packages in the GIT tree that rely libtools/autotools to build. More testing will need to confirm. Essentially what happens is that during make the following call is made for every file compiled:

$to_tool_file_cmd $1

  When to_tool_file_cmd is uninitialized, you get: '"" $1' for each file during build resulting in errors like (for ark_part.cpp):

../libtool: line 2083: ark_part.cpp: command not found

  A (post-configure) work-around with tdeutils was found by explicitly hacking the libtool file generated by ./configure and including a declaration for 'to_tool_file_cmd' within libtool as follows:

to_tool_file_cmd=func_convert_file_noop

  The 'func_convert_file_noop' value is the default value according to:

http://www.gnu.org/software/libtool/manual/html_node/libtool-script-contents.html

<quote>

— Variable: to_tool_file_cmd

    If the toolchain is not native to the build platform (e.g. if you are using
some Unix to drive the scripting together with a Windows toolchain running in
Wine) this variable describes how to convert file names from the format used by
the build platform to the format used by the toolchain. Normally set to
‘func_convert_file_noop’.

</quote>

  The post-configure work-around was accomplished with the following sed call:

  cd ${srcdir}/${pkgname#*-}
  make -f admin/Makefile.common

  ./configure \
    --prefix=${TDEDIR} \
    --with-qt-dir=${QTDIR} \
    --sysconfdir=/etc \
    --localstatedir=/var \
    --enable-debug=full \
    --enable-closure

  ## hack to get around to_tool_file_cmd failure, set to func_convert_file_noop
  sed -i '/#! \/bin\/sh/s|$|\n\nto_tool_file_cmd=func_convert_file_noop\n|' libtool

  ## make
  make

  After including the to_tool_file_cmd declaration, tdeutils built and works fine.

  I have designated this bug as a blocker for R14. It would be bad to release R14 knowing tdeutils building would break in every distro that updates to the current stable libtool version. 

  I don't know how difficult it is to update the libtool version that the GIT source contains, but if that is doable, then that appears to be the proper solutions. A current libtool in GIT would be backwards compatible with older system versions of libtool, but the converse is not true. If it is simple enough to do, then all tde packages that depend on libtools/autofoo should be updated with the current tools.

  If this needs to be reduced from 'blocker' to something else, feel free. Thinking about the impact on people attempting to build, it just seemed that was the correct category for it.

  I will report additional failures with libtool as I find them to help get a handle on the extent of the issue.
Comment 1 David C. Rankin 2012-03-22 18:28:19 CDT 
tdeaddons suffers a similar libtool version mismatch failure, but there is no apparent work-around:

make[4]: Entering directory `/build/src/tdeaddons/kaddressbook-plugins/xxports/kworldclock'
/bin/sh ../../../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h  -I/opt/trinity/include/tde  -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 geo_xxport.lo -MD -MP -MF .deps/geo_xxport.Tpo -c -o geo_xxport.lo geo_xxport.cpp
libtool: Version mismatch error.  This is libtool 2.2.6b Debian-2.2.6b-2ubuntu1, but the
libtool: definition of this LT_INIT comes from libtool 2.4.2.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b Debian-2.2.6b-2ubuntu1
libtool: and run autoconf again.
make[4]: *** [geo_xxport.lo] Error 63
make[4]: Leaving directory `/build/src/tdeaddons/kaddressbook-plugins/xxports/kworldclock'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/build/src/tdeaddons/kaddressbook-plugins/xxports'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/build/src/tdeaddons/kaddressbook-plugins'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/build/src/tdeaddons'
make: *** [all] Error 2

I've tried
make maintainer-clean
autoreconf --force
Comment 2 David C. Rankin 2012-03-22 19:38:39 CDT 
for tdeaddons -- the libtool hack did get past the libtool error after:

  autoreconf --force --install

However, the same libtool failure occurred with tdeaddons:

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../.. -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -I/opt/trinity/include/tde -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 geo_xxport.lo -MD -MP -MF .deps/geo_xxport.Tpo
 -c ""  -fPIC -DPIC -o .libs/geo_xxport.o
   ^^^^^^^
g++: error: : No such file or directory
g++: fatal error: no input files

  That was due to to_tool_file_cmd being undefined. Worked-around with the hack of libtool with sed:

  sed -i '/#! \/bin\/sh/s|$|\n\nto_tool_file_cmd=func_convert_file_noop\n|' libtool


So this is the third point in the line. Unfortunately, I have other build issues with tdeaddons: geo_xxport.cpp:114:26: fatal error: geo_xxport.moc: No such file or directory...
Comment 3 David C. Rankin 2012-03-23 11:29:23 CDT 
According to the gnu developers, this is not a bug with libtool, but a problem in the TDE code. Initially the developers thought there may be an issue that could be solved like this:

diff --git a/m4/libtool.m4 b/m4/libtool.m4
index 75bfdb4..45a988f 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -7862,6 +7862,9 @@ case $host in
         ;;
     esac
     ;;
+  * ) # unhandled hosts (and "normal" native builds)
+    lt_cv_to_tool_file_cmd=func_convert_file_noop
+    ;;
 esac
 ])
 to_tool_file_cmd=$lt_cv_to_tool_file_cmd 

However, after providing the build.log and failing libtool to the devs, they concluded that it was TDE:

<quote>

close 11060
tags 11060 notabug
thanks

Hi David,

On 03/23/2012 10:44 AM, David C. Rankin wrote:
> On 03/22/2012 10:41 AM, Peter O'Gorman wrote:
>
> Peter,
>
> Attached is the config.log, the failing libtool and the tdeutils
> build.log. I apologize that I couldn't immediately figure out where to
> put the '--debug' to make it appear right after libtool? (Makefile?,
> CFLAGS?) If I haven't given you what you need, just let me know and I'll
> send it. The error is clear:

I think there is another copy of a different version libtool.m4 inculded in acinclude.m4, and that's causing the problem

The libtool m4 macros that match the ltmain script do properly set these variables as Peter noted yesterday.

To update the included libtool, you will have to edit acinclude.m4 also.

Thanks,
Peter 

</quote>
Comment 4 David C. Rankin 2012-03-23 12:00:32 CDT 
I think the problem is cvs.sh:

cat admin/acinclude.m4.in admin/libtool.m4.in admin/pkg.m4.in $adds > acinclude.m4

this includes the old libtool.m4.in in acinclude.m4. 

As a workaround, I have done the following:

  cp /usr/share/aclocal/libtool.m4 ./admin
  cp /usr/share/aclocal/libtool.m4 ./admin/libtool.m4.in
  cp /usr/share/libtool/config/ltmain.sh ./admin

That solves the issue with tdeutils
Comment 5 David C. Rankin 2012-03-23 12:48:50 CDT 
I am closing this bug and retaking kindergarten -- in order to re-learn how to read.