Or: "Lions and tigers and ebuilds, oh my!"
Yes, I know there are no official packages for Gentoo yet. I decided to see if I could do something useful by installing what unofficial ones were available and probing for bugs, and possibly rolling a few ebuilds of my own for the packages that haven't gotten any love yet. I used non7top's GitHub fork of Serghei's ebuild repository (at the time I started, the contents of the two were identical, actually) and did manage to get kdebase installed after two ebuild- related hiccups.
After that, things started to get complicated, and I ran into a variety of problems. Unfortunately, I haven't been able to decide whether some of them are Trinity bugs, ebuild bugs, or just Gentoo quirks, so I don't know where to file them and need help with the triage.
__________________
Problem #1: Unset environment variables
When I first booted Trinity, the desktop *appeared* to come up exactly as it should, but most applications would not start, the main menu was nearly empty, and kcontrol had no settings available. After some mucking around, I discovered that there was no mention of the Trinity bin directory in my PATH, and then found that Gentoo set PATH, ROOTPATH, LDPATH, and XDG_DATA_DIRS inside a distro-specific part of starkde (for KDE 3.5.10, that is), so I copy-and-pasted those into the startup file provided. (I know there are some setters in the Trinity startup script. They didn't work, possibly because of Problem #4.)
Unfortunately, that didn't fix things--I also needed to set LD_LIBRARY_PATH for programs (including konsole) to start properly, and XDG_DATA_HOME, XDG_CONFIG_HOME, and/or XDG_CONFIG_DIRS (I never tried setting them individually, so I can't narrow it down) to get a working menu and kcontrol.
I don't know what changed between KDE 3.5.10 and Trinity 3.5.13 to make the setting of those additional environment variables necessary, so I'm not sure who owns the second half of the bug.
__________________
Problem #2: Autotools packages and ebuilds
I did manage to write some successful ebuilds (I have most of kdegraphics and kdeartwork working, if anyone wants ebuilds for those, plus kdebase-meta and a variant ksmserver ebuild with a hal useflag), but only for packages that have been ported to CMake. The autotools packages Will Not Work, no matter how I mangle the KDE 3.5.10 ebuilds (rewriting from scratch is not an option, IMAO--the old kde-meta eclass contains several hundred lines of bash script, and spending more than minimal time on a build system that's going away is wasted effort).
After a lot of playing around with kdetoys, I was able to figure out that I was running into two problems: a minor change in the tarball structure (not a bug, solved by a 1-line fix), and a set of missing build/config files. The kdetoys-3.5.10 tarball contains a bunch of files at the top level that are missing from its 3.5.13 equivalent: configure.in, acinclude.m4, aclocal.m4, and several other config* and Makefile* files. When I copied these files from the old to the new package, the ebuild got as far as actually configuring/building the package (and, naturally, failed, because the old buildscripts didn't know about TQT, but it was the first iteration that didn't bail out while trying to find the build directory or run eautoreconf/aclocal).
I know next to nothing about autotools, so I don't know if those files were removed for a reason. Maybe someone who knows more about autotools and ebuilds could do something without them; I just know that *I* can't.
Another thing is that I couldn't seem to get the --without-arts switch to work, but with the ebuilds so messed up to begin with it's difficult to tell whether that's meaningful.
__________________
Problem #3: CMake failures
Ebuilds for two subapplications of kdeutils that were included in the stuff I took from GitHub failed to build, complaining that they weren't able to find tqt.h (one of them would have been Ark). I don't know whether this is an ebuild or a CMake bug.
__________________
Problem #4: startkde/starttrinity and minimal or unusual builds
While I was wrestling with Problem #1 above, I had occasion to examine both the new and the old startup scripts in detail, and there were some things in the new one that drew my attention. However, I'm not sure they really qualify as bugs:
if [ -d /opt/trinity/games ]; then
That, and the lines that follow it, might work fine if Trinity is installed into /opt/trinity/, but Gentoo's practice is to install most software into /usr/. Something like:
if [ -d ${KDEDIR}/games ]; then
might be more portable.
# Make sure a default wallpaper is set. if [ ! -e $kdehome/share/config/kdesktoprc ]; then # With Trinity this file should exist, but test first. if [ -r /usr/share/wallpapers/isadora.png.desktop ]; then cat >$kdehome/share/config/kdesktoprc <<EOF [Desktop0] Wallpaper=isadora.png WallpaperMode=Scaled EOF fi fi
Not having a wallpaper set is harmless--these lines seem to add complexity to the script for no good reason (and I don't have a /usr/share/wallpapers, either-- isadora.png is in /usr/kde/3.5/share/wallpapers--so this code isn't portable). Perhaps it belongs in a distro-specific patch?
# Configuration of the gtk_qt_engine if not already set. [...]
Trinity will run quite happily without gtk-qt-engine installed, so a test needs to be made for that (at minimum--I'd relegate this to "distro-specific" too).
# Remove moodin cache if we have a new wallpaper installed, jriddell. Distro-specific. if [ -d $kdehome/share/apps/ksplash/cache/Moodin/kubuntu ]; then if [ /usr/share/wallpapers/kubuntu-wallpaper.png -nt $kdehome/share/apps/ksplash/cache/Moodin/kubuntu/ ]; then rm -rf $kdehome/share/apps/ksplash/cache/Moodin/kubuntu/ fi fi
This says right out that it's a Kubuntu patch. It doesn't belong in vanilla Trinity.
$KDEDIR/bin/artsshell -q terminate
Arts is another optional component that Trinity can operate without, so it shouldn't be shut down without testing to see if it's there. Maybe:
if test -e $KDEDIR/bin/artsshell ; then artsshell -q terminate ; fi
(The prelinking stuff isn't in my old startup script either, but I suspect that Gentoo may have removed it.)
__________________
I think that's everything. The other (minor) bugs I ran into I'm fairly sure I know where to file.
Yes, I know there are no official packages for Gentoo yet. I decided to see if I could do something useful by installing what unofficial ones were available and probing for bugs, and possibly rolling a few ebuilds of my own for the packages that haven't gotten any love yet. I used non7top's GitHub fork of Serghei's ebuild repository (at the time I started, the contents of the two were identical, actually) and did manage to get kdebase installed after two ebuild- related hiccups.
After that, things started to get complicated, and I ran into a variety of problems. Unfortunately, I haven't been able to decide whether some of them are Trinity bugs, ebuild bugs, or just Gentoo quirks, so I don't know where to file them and need help with the triage.
Problem #1: Unset environment variables
When I first booted Trinity, the desktop *appeared* to come up exactly as it should, but most applications would not start, the main menu was nearly empty, and kcontrol had no settings available. After some mucking around, I discovered that there was no mention of the Trinity bin directory in my PATH, and then found that Gentoo set PATH, ROOTPATH, LDPATH, and XDG_DATA_DIRS inside a distro-specific part of starkde (for KDE 3.5.10, that is), so I copy-and-pasted those into the startup file provided. (I know there are some setters in the Trinity startup script. They didn't work, possibly because of Problem #4.)
Unfortunately, that didn't fix things--I also needed to set LD_LIBRARY_PATH for programs (including konsole) to start properly, and XDG_DATA_HOME, XDG_CONFIG_HOME, and/or XDG_CONFIG_DIRS (I never tried setting them individually, so I can't narrow it down) to get a working menu and kcontrol.
I don't know what changed between KDE 3.5.10 and Trinity 3.5.13 to make the setting of those additional environment variables necessary, so I'm not sure who owns the second half of the bug.
Problem #2: Autotools packages and ebuilds
I did manage to write some successful ebuilds (I have most of kdegraphics and kdeartwork working, if anyone wants ebuilds for those, plus kdebase-meta and a variant ksmserver ebuild with a hal useflag), but only for packages that have been ported to CMake. The autotools packages Will Not Work, no matter how I mangle the KDE 3.5.10 ebuilds (rewriting from scratch is not an option, IMAO--the old kde-meta eclass contains several hundred lines of bash script, and spending more than minimal time on a build system that's going away is wasted effort).
After a lot of playing around with kdetoys, I was able to figure out that I was running into two problems: a minor change in the tarball structure (not a bug, solved by a 1-line fix), and a set of missing build/config files. The kdetoys-3.5.10 tarball contains a bunch of files at the top level that are missing from its 3.5.13 equivalent: configure.in, acinclude.m4, aclocal.m4, and several other config* and Makefile* files. When I copied these files from the old to the new package, the ebuild got as far as actually configuring/building the package (and, naturally, failed, because the old buildscripts didn't know about TQT, but it was the first iteration that didn't bail out while trying to find the build directory or run eautoreconf/aclocal).
I know next to nothing about autotools, so I don't know if those files were removed for a reason. Maybe someone who knows more about autotools and ebuilds could do something without them; I just know that *I* can't.
Another thing is that I couldn't seem to get the --without-arts switch to work, but with the ebuilds so messed up to begin with it's difficult to tell whether that's meaningful.
Problem #3: CMake failures
Ebuilds for two subapplications of kdeutils that were included in the stuff I took from GitHub failed to build, complaining that they weren't able to find tqt.h (one of them would have been Ark). I don't know whether this is an ebuild or a CMake bug.
Problem #4: startkde/starttrinity and minimal or unusual builds
While I was wrestling with Problem #1 above, I had occasion to examine both the new and the old startup scripts in detail, and there were some things in the new one that drew my attention. However, I'm not sure they really qualify as bugs:
if [ -d /opt/trinity/games ]; then
That, and the lines that follow it, might work fine if Trinity is installed into /opt/trinity/, but Gentoo's practice is to install most software into /usr/. Something like:
if [ -d ${KDEDIR}/games ]; then
might be more portable.
# Make sure a default wallpaper is set. if [ ! -e $kdehome/share/config/kdesktoprc ]; then # With Trinity this file should exist, but test first. if [ -r /usr/share/wallpapers/isadora.png.desktop ]; then cat >$kdehome/share/config/kdesktoprc <<EOF [Desktop0] Wallpaper=isadora.png WallpaperMode=Scaled EOF fi fi
Not having a wallpaper set is harmless--these lines seem to add complexity to the script for no good reason (and I don't have a /usr/share/wallpapers, either-- isadora.png is in /usr/kde/3.5/share/wallpapers--so this code isn't portable). Perhaps it belongs in a distro-specific patch?
# Configuration of the gtk_qt_engine if not already set. [...]
Trinity will run quite happily without gtk-qt-engine installed, so a test needs to be made for that (at minimum--I'd relegate this to "distro-specific" too).
# Remove moodin cache if we have a new wallpaper installed, jriddell. Distro-specific. if [ -d $kdehome/share/apps/ksplash/cache/Moodin/kubuntu ]; then if [ /usr/share/wallpapers/kubuntu-wallpaper.png -nt $kdehome/share/apps/ksplash/cache/Moodin/kubuntu/ ]; then rm -rf $kdehome/share/apps/ksplash/cache/Moodin/kubuntu/ fi fi
This says right out that it's a Kubuntu patch. It doesn't belong in vanilla Trinity.
$KDEDIR/bin/artsshell -q terminate
Arts is another optional component that Trinity can operate without, so it shouldn't be shut down without testing to see if it's there. Maybe:
if test -e $KDEDIR/bin/artsshell ; then artsshell -q terminate ; fi
(The prelinking stuff isn't in my old startup script either, but I suspect that Gentoo may have removed it.)
I think that's everything. The other (minor) bugs I ran into I'm fairly sure I know where to file.
Welcome!
A couple of things that might help. The startkde script provided in 3.5.13 needs love and attention. I uploaded a revised script in bug report 675:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=675
You'll find a patch diff and a full script in the attachments. Please test! Please patch! One note: Bear in mind there are many distros to support and the script needs to be flexible for everybody. Don't arbitrarily rip snippets from the script but instead add error checking and tests when to run a snippet in the script.
The code upon which TDE was born was not the vanilla code directly from the upstream KDE sources. They were Debianized sources and yes, modified for Kubuntu too. Now that people using different distros are involved a lot of that Debianization is being remedied. Everybody here will be grateful for any help you provide.
Not all of the packages have been ported to cmake. Here are the ones I know that have been converted:
Core packages: tqtinterface arts kdelibs kdebase
Other: amarok dbus-1-tqt dbus-tqt kdeartwork kdegraphics kdenetwork kdepim kdevelop
Use autotools to build the other packages.
The wiki has basic instructions for building but needs somebody new (unfamiliar) to help improve those instructions.
Know too that not everybody uses all of the packages in the source tree. So that means some of those non main packages are not tested as well as core packages.
Browse the bugzilla for patches to the packages. Every distro is different and many packages will not build without those patches. Those patches will get merged when the SVN to GIT conversion is completed. Until then just backport the patches as necessary.
The GIT repository is not ready for use. Tim (project leader) is still converting everything from SVN. He also is implementing a massive file and package renaming scheme before opening GIT to all of us. So don't use GIT, just use the 3.5.13 tarballs. :)
Darrell
On Tue, 29 Nov 2011 16:07:27 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
(Things got hectic for me after my original message was sent and I never got around to replying to this. Or filing those bugs. Mea culpa. I'll do the bugs soon.)
Welcome!
A couple of things that might help. The startkde script provided in 3.5.13 needs love and attention. I uploaded a revised script in bug report 675:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=675
You'll find a patch diff and a full script in the attachments. Please test! Please patch! One note: Bear in mind there are many distros to support and the script needs to be flexible for everybody. Don't arbitrarily rip snippets from the script but instead add error checking and tests when to run a snippet in the script.
The startup script I eventually ended up using was created by combining parts of one of the scripts you posted here with the Gentoo KDE 3.5.10 startup script (and adding a few extra variable setters to fix the problems I ran into). It is extensively stripped and probably not suited for general use by other distros as-is, but I'll check the bug and see about posting a diff for any useful bits.
The code upon which TDE was born was not the vanilla code directly from the upstream KDE sources. They were Debianized sources and yes, modified for Kubuntu too. Now that people using different distros are involved a lot of that Debianization is being remedied. Everybody here will be grateful for any help you provide.
Not all of the packages have been ported to cmake. Here are the ones I know that have been converted:
Core packages: tqtinterface arts kdelibs kdebase
Personally, I wouldn't consider aRts a core package--KDE 3.5.10 runs perfectly well without it, and I expect Trinity will too, unless there have been extensive changes. (I haven't set up sound inside my testing VM yet, or I would know for certain.)
Other: amarok dbus-1-tqt dbus-tqt kdeartwork kdegraphics kdenetwork kdepim kdevelop
Use autotools to build the other packages.
Part of the problem is that I am trying to package some of the peripheral, non-core parts of Trinity for Gentoo. I was hoping to make things easier for Serghei and the others involved in the Gentoo packaging effort, which seems to have even less manpower available than the main Trinity project and is moving forward very slowly.
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.
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).
Without the missing files, these packages are going to have to wait for the attention of someone who knows more about Portage and autotools than I do, which might take a long time. It would also be wasted time, with the CMake port in process. I'd like to see Gentoo able to offer a full set of Trinity packages before the latter hits v15, though.
The wiki has basic instructions for building but needs somebody new (unfamiliar) to help improve those instructions.
Know too that not everybody uses all of the packages in the source tree. So that means some of those non main packages are not tested as well as core packages.
Given that I've been installing everything piecemeal according to what I could persuade Portage to handle, I suspect I know this better than most (I basically had only kdebase, kdelibs, and tqtinterface installed when I first started Trinity up). I had intended to test the handful of non-core applications that I use under KDE 3.5.10 (Filelight, K3B, the Tiblit widget style if I can get it to build, and some stuff from kdegraphics, kdemultimedia, and kdeutils), but that was before I ran into the build problems with Portage.
It's nice to see the flaky compositing bugs I keep getting with KDE 3 gone, anyway. :)
The startup script I eventually ended up using was created by combining parts of one of the scripts you posted here with the Gentoo KDE 3.5.10 startup script (and adding a few extra variable setters to fix the problems I ran into). It is extensively stripped and probably not suited for general use by other distros as-is, but I'll check the bug and see about posting a diff for any useful bits.
Please file any patches. :)
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).
If you post or link to your build logs I'm sure the heavy hitters will help. I'm not a coder, just a packager and one of the people who monkey wrenches everything to find the breakage. :)
Darrell
On Tue, 6 Dec 2011 19:07:14 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
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).
If you post or link to your build logs I'm sure the heavy hitters will help. I'm not a coder, just a packager and one of the people who monkey wrenches everything to find the breakage. :)
Fortunately, the pertinent portions of the logs are short:
* Package: kde-base/amor-3.5.13 * Repository: trinity * Maintainer: kde@gentoo.org * USE: elibc_glibc kernel_linux userland_GNU x86 * FEATURES: sandbox
Unpacking source... Unpacking parts of kdetoys-3.5.13.tar.bz2 to /var/tmp/portage/kde-base/amor-3.5.13/work Unpacking kdetoys-3.5.13.tar.gz to /var/tmp/portage/kde-base/amor-3.5.13/work
* Running eautoreconf in '/var/tmp/portage/kde-base/amor-3.5.13/work/amor-3.5.13' ... * Running aclocal ... [ !! ]
* Failed Running aclocal ! * * Include in your bugreport the contents of: * * /var/tmp/portage/kde-base/amor-3.5.13/temp/aclocal.out
aclocal.out contains the following, which I think is pretty clear:
***** aclocal ***** ***** PWD: /var/tmp/portage/kde-base/amor-3.5.13/work/amor-3.5.13 ***** aclocal
aclocal-1.9: `configure.ac' or `configure.in' is required
The output should look like this (produced by doping the source tarball with a configure.in from 3.5.10, which causes the build not to fail until configure is actually run):
* Package: kde-base/kodo-3.5.13 * Repository: trinity * Maintainer: kde@gentoo.org * USE: elibc_glibc kernel_linux userland_GNU x86 * FEATURES: sandbox
Unpacking source... Unpacking parts of kdetoys-3.5.13.tar.bz2 to /var/tmp/portage/kde-base/kodo-3.5.13/work Unpacking kdetoys-3.5.13.tar.gz to /var/tmp/portage/kde-base/kodo-3.5.13/work
* Running eautoreconf in '/var/tmp/portage/kde-base/kodo-3.5.13/work/kodo-3.5.13' ... * Running aclocal ... [ ok ] * Running libtoolize --copy --force --install --automake ... [ ok ] * Running aclocal ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --foreign ... [ ok ] * Running elibtoolize in: kodo-3.5.13/admin/ * Applying portage/1.2.0 patch ... * Applying sed/1.5.6 patch ... * Applying as-needed/2.2.6 patch ...
Source unpacked in /var/tmp/portage/kde-base/kodo-3.5.13/work Compiling source in /var/tmp/portage/kde-base/kodo-3.5.13/work/kodo-3.5.13 ...
* econf: updating kodo-3.5.13/admin/config.guess with /usr/share/gnuconfig/config.guess * econf: updating kodo-3.5.13/admin/config.sub with /usr/share/gnuconfig/config.sub ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --with-qt-dir=/usr/qt/3 --enable-mt --with-qt-libraries=/usr/qt/3/lib --disable-dependency-tracking --disable-debug --without-debug --without-arts --prefix=/usr/kde/3.5 --mandir=/usr/kde/3.5/share/man --infodir=/usr/kde/3.5/share/info --datadir=/usr/kde/3.5/share --sysconfdir=/usr/kde/3.5/etc
(configure then fails because it can't find the designer plugins, which I assume is because the old configure.in doesn't know about tqt)
More files are available, including the rest of that last log with the list of configure checks passed/failed, the system setup data, documentation for the e[foo] functions used by Portage, and the 1000+ lines of shellscript forming the backbone of the old KDE3 build system for Gentoo which I am trying to adapt.
On Tue, 6 Dec 2011 19:07:14 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
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).
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.
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.
Hopefully somebody here more qualified than me answers, but where did you install Qt3? Most of us here have been setting $PREFIX to /opt/trinity and avoid installing anything other than tqtinterface to /usr. TQtinterface is the only package that is installed to /usr. If you have the old Qt3 from KDE3 installed to /usr, or Qt4 installed, which defaults to /usr/qt, and the environment variables reflect that location, then none of the other packages find the correct Trinity qt3.
Darrell
On Fri, 9 Dec 2011 15:12:15 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
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.
Hopefully somebody here more qualified than me answers, but where did you install Qt3? Most of us here have been setting $PREFIX to /opt/trinity and avoid installing anything other than tqtinterface to /usr. TQtinterface is the only package that is installed to /usr. If you have the old Qt3 from KDE3 installed to /usr, or Qt4 installed, which defaults to /usr/qt, and the environment variables reflect that location, then none of the other packages find the correct Trinity qt3.
QT3.3.8d is the only version of QT installed in my test VM. It's at /usr/qt/3, but if its location were the problem, I'd be expecting the build to fail while testing for QT in the configure phase, which it never has. Furthermore, the Makefile for the failed compile has:
MOC = /usr/qt/3/bin/moc QT_INCLUDES = -I/usr/qt/3/include -include tqt.h QT_LDFLAGS = -L/usr/qt/3/lib -ltqt qt_includes = /usr/qt/3/include qt_libraries = /usr/qt/3/lib
so it doesn't seem likely that it's failing to find anything.
-
Darrell Anderson -
E. Liddell