9 Dec
2011
9 Dec
'11
9:04 p.m.
On Tue, 6 Dec 2011 19:07:14 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
Okay, I was getting somewhere with this for a while, but now I seem
to have hit another snag. I borrowed a configure.in from KDE 3.5.10
and was able to recreate what I think is the correct acinclude.m4 using
the admin/acinclude.m4.in and admin/libtool.m4.in from kdetoys-3.5.13.
Using those, I was able to get amor past the configure stage with Portage,
but it fails in mid-build due to missing moc files (full log in attachment):
make[3]: Entering directory
`/var/tmp/portage/kde-base/amor-3.5.13/work/amor-3.5.13/amor'
i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/kde/3.5/include
-I/usr/qt/3/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 -DNDEBUG -DNO_DEBUG -O2 -O2 -march=i686 -pipe -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 -c -o amordialog.o amordialog.cpp
i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/kde/3.5/include
-I/usr/qt/3/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 -DNDEBUG -DNO_DEBUG -O2 -O2 -march=i686 -pipe -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 -c -o amor.o amor.cpp
amordialog.cpp:35:26: fatal error: amordialog.moc: No such file or directory
compilation terminated.
"which moc" gives "/usr/qt/3/bin/moc", for what it's worth.
The thing is,
I cannot get Portage, Gentoo's package
manager, to build the packages that still use
autotools.
(CMake-based packages are okay.) I apparently need
the configure.in and supporting files that are
missing from the root level of the source tarballs for
3.5.13 so that Portage can regenerate the
other configuration files.
I don't know what black magic Tim used to get autotools to work again, but I am able
to build packages with
autotools that have not yet been ported to cmake. That does not help you immediately, but
lets you know that autotools does work.
> Unfortunately, I suspect that Timothy Pearson is the only
> person who might be able to produce these files.
> I'm hesitant to file a bug about this because the problem
> is 1. with autotools and 2. probably limited to
> distros using ebuilds/Portage, of which there are only
> about three (Gentoo, Funtoo, and kinda-sorta
> Sabayon).