Confirmed,
Libtool version mismatch resulting in undeclared 'to_tool_file_cmd' is common to all tde modules requiring autoconf. With tdeaddons, after issuing:
autoreconf --force --install
to get past the initial libtool version mismatch, the build again failed with:
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
Note the empty filename:
.deps/geo_xxport.Tpo -c "" -fPIC -DPIC -o .libs/geo_xxport.o ^^^^^^
So here is our third point in the line. I've updated http://bugs.pearsoncomputing.net/show_bug.cgi?id=924 with the new information.
Additionally, I have additional work to do on tdeaddons. After sorting the libtool issue, I ran into:
geo_xxport.cpp:114:26: fatal error: geo_xxport.moc: No such file or directory compilation terminated.
So there is something going on there I don't quite understand...
On 03/22/2012 07:43 PM, David C. Rankin wrote:
Confirmed,
Libtool version mismatch resulting in undeclared 'to_tool_file_cmd' is common to all tde modules requiring autoconf. With tdeaddons, after issuing:
I have filed a bug report with gnu regarding the libtool issue and I'm currently working with the developer. So far, here is the initial response I have received:
It looks like this isn't getting set to the default in libtool.m4, but it's strange that our test suite didn't notice (and that this is the first report of it).
Could you please send me a failing build log, and perhaps run a failing libtool command with an added --debug flag (right after the 'libtool') and send the output of that also.
Then we can come up with a test that fails, right now it seems the fix is something like:
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
Thanks, Peter
I'll keep you posted as I get more information.
On 03/23/2012 10:54 AM, David C. Rankin wrote:
On 03/22/2012 07:43 PM, David C. Rankin wrote:
Confirmed,
Libtool version mismatch resulting in undeclared 'to_tool_file_cmd' is common to all tde modules requiring autoconf. With tdeaddons, after issuing:
I have filed a bug report with gnu regarding the libtool issue and I'm currently working with the developer. So far, here is the initial response I have received:
It looks like this isn't getting set to the default in libtool.m4, but it's strange that our test suite didn't notice (and that this is the first report of it).
Could you please send me a failing build log, and perhaps run a failing libtool command with an added --debug flag (right after the 'libtool') and send the output of that also.
Then we can come up with a test that fails, right now it seems the fix is something like:
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
Thanks, Peter
I'll keep you posted as I get more information.
Well, it isn't a libtool bug, but problem with the current setup on the TDE code. Here is the response from the gnu:
<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>
I know nothing about the autoconf syntax or wizardry that goes on inside the files, so we will need to find someone on the list that has that knowledge to help with the code fix. I'll update the bug report with this information.
On 03/23/2012 11:30 AM, David C. Rankin wrote: <snip>
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.
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
I'll test it, but I'm pretty sure that is what is screwing things up.
On 03/23/2012 11:42 AM, David C. Rankin wrote:
On 03/23/2012 11:30 AM, David C. Rankin wrote:
<snip> > 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.
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
I'll test it, but I'm pretty sure that is what is screwing things up.
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
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
That is exactly what the wiki says to do.
http://www.trinitydesktop.org/wiki/bin/view/Developers/HowToBuild
3. Building with autoconf ... Regenerate Autoconf/Automake files
Perhaps you thought you had been doing this all along but now discover that you haven't? (Been there, done that!) :)
Darrell
On 03/23/2012 12:18 PM, Darrell Anderson wrote:
- Building with autoconf
... Regenerate Autoconf/Automake files
Perhaps you thought you had been doing this all along but now discover that you haven't? (Been there, done that!) :)
Darrell
<dunce cap donned and turned facing the corner> :)
I completely missing the '.in' at the end of the copy. You can see from my prior posts, I was attempting:
cp /usr/share/aclocal/libtool.m4 ./admin cp /usr/share/libtool/config/ltmain.sh ./admin
Oh the forest for the trees issues.... and the time they take to solve. I think this solves the remainder of the issues as well :)
<dunce cap donned and turned facing the corner> :)
I completely missing the '.in' at the end of the copy. You can see from my prior posts, I was attempting:
cp /usr/share/aclocal/libtool.m4 ./admin cp /usr/share/libtool/config/ltmain.sh ./admin
Oh the forest for the trees issues.... and the time they take to solve. I think this solves the remainder of the issues as well :)
Ah, well, we all have been there and will be again. I can't count the number of "lessons" I have failed to master in my life time. :)
For Trinity I use a functions container file in my build environment. I source that container file in all related build scripts. In that file are the lines to regenerate the libtools files. Then in each package build script I call the function.
Darrell
-
Darrell Anderson -
David C. Rankin