Try adding this to your configure string: DO_NOT_COMPILE='dcopperl kalyptus qtsharp xparts python'

Treat it as a configure flag; e.g. if your configure command was: ./configure --prefix=/opt/trinity

the new command would be: ./configure --prefix=/opt/trinity DO_NOT_COMPILE='dcopperl kalyptus qtsharp xparts python'

From what I can tell gcc might be trying to compile something it shouldn't.  The above line was required under Debian, but does not remove any functionality from the resulting build as far as I can tell.

Okay. The package finally built. The package size is about 8 MB, which is about 6 MB smaller than the stock 3.5.10 package. I have not yet compared the package contents.

Possibly unrelated whatsoever, but when I was tinkering with Lenny earlier this year I never got rpc.rwalld to work with the KDE write daemon to provide KDE popups from rwalld messages. I wonder whether no functionality is lost.

That new info makes me wonder as well.  I guess we'll find out!  Either way, I don't think I'll be able to reactivate/fix such a large chunk of code before the 3.5.12 release; it will probably have to wait 6 months or so for 3.5.13.

As I mentioned the problem could be unrelated.

I use rwalld to keep my htpc communicating with my office system, which is the computer I spend the most time. I get nice little popups at my office machine. I'm always tinkering and experimenting with my htpc and I need the communications mechanism to know what the htpc is doing so I can monitor.

I might very well have migrated to Debian this past spring if I had solved that one little problem. I could still migrate to Debian if I ever solve that problem.

I played with the configure parameters you provided.

First pass, all parameters: DO_NOT_COMPILE='dcopperl kalyptus qtsharp xparts python'

Compiled.

Second pass: DO_NOT_COMPILE='kalyptus qtsharp xparts python'

Compiled.

Third pass: DO_NOT_COMPILE='python'

Compiled.

Perhaps then we're no longer talking about large chunks. Just one element. At least now we know the problem area.

Package size remains at about 8 MB. Obvious then is the python bindings comprise a significant portion of the package.

Of course, python bindings are important to many people.

Amarok scripts are written in python, but I don't know whether those scripts depend upon kdebindings or are just run external to Amarok.

I might have narrowed the focus for kdebindings. :)

In my build script, after I run libtools to auto-generate the makefiles, and before I run configure, I copied the original stock 3.5.10 python/sip/sipgen directory files over the svn version. (Remember that during my builds my svn version of the package sources are in tmpfs.)

By golly the build did not fail at the same point.

Comparing the 3.5.10 and svn python/sip/sipgen directories reveals the svn version referencing TQT interface objects. I'm guessing the previous build failures have something to do with that.

My on-the-fly replacement of the files removed the TQT interface references.

Based upon the many past fixes I've seen, I suspect the solution might be some <include tqt*whatever.h. statements.

The previous failures always took place in lexer.l. I do not notice any <include tqt*whatever.h> statements. That might be the only file that needs appropriate include statements, but also might mean the compile only stopped at that point and other files in that same directory need similar include statements.

The build eventually failed:

========================================== make[4]: Entering directory `/dev/shm/kdebindings/python/pykde/kdeui' g++ -c -Wno-deprecated-declarations -pipe -fPIC -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_THREAD_SUPPORT -I. -I../extra/kde353 -I/usr/include -I/dev/shm/kdebindings/python/sip/siplib -I/usr/include/python2.5 -I/usr/lib/qt/mkspecs/default -I/usr/lib/qt//include -I/usr/X11R6/include -o sipkdeuiKInputDialog.o sipkdeuiKInputDialog.cpp In file included from sip/kdeui/kinputdialog.sip:32, from sipkdeuiKInputDialog.cpp:25: /usr/include/kinputdialog.h:58: error: 'QValidator' has not been declared /usr/include/kinputdialog.h:119: error: 'QValidator' has not been declared /usr/include/kinputdialog.h:132: error: 'QValidator' has not been declared sipkdeuiKInputDialog.cpp: In function 'PyObject* meth_KInputDialog_getText(PyObject*, PyObject*)': sipkdeuiKInputDialog.cpp:116: error: no matching function for call to 'KInputDialog::getText(const QString&, const QString&, const QString&, bool*, QWidget*&, const char*&, QValidator*&, const QString&)' /usr/include/kinputdialog.h:120: note: candidates are: static QString KInputDialog::getText(const QString&, const QString&, const QString&, bool*, QWidget*, const char*, int*, const QString&) sipkdeuiKInputDialog.cpp: In function 'PyObject* meth_KInputDialog_text(PyObject*, PyObject*)': sipkdeuiKInputDialog.cpp:163: error: no matching function for call to 'KInputDialog::text(const QString&, const QString&, const QString&, bool*, QWidget*&, const char*&, QValidator*&, const QString&, const QString&)' /usr/include/kinputdialog.h:134: note: candidates are: static QString KInputDialog::text(const QString&, const QString&, const QString&, bool*, QWidget*, const char*, int*, const QString&, const QString&) make[4]: *** [sipkdeuiKInputDialog.o] Error 1 make[4]: Leaving directory `/dev/shm/kdebindings/python/pykde/kdeui' make[3]: *** [all] Error 2 make[3]: Leaving directory `/dev/shm/kdebindings/python/pykde' make[2]: *** [build_pyqt_pykde] Error 2 make[2]: Leaving directory `/dev/shm/kdebindings/python' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/dev/shm/kdebindings' make: *** [all] Error 2 ==========================================

I believe those errors are related to my copying the original sipgen files. The build ran for about 26 minutes before failing, unlike the previous 3 and half minutes. Thus, I'm encouraged we might now be on the right track of solving this problem.

I hope that helps!

I did some poking around the Trinity source tree, and it appears the reason for the build failures is outdated code. Eons ago Debian split out the three components contained in kdebindings into different source packages.

The components are: SIP PyQt PyKDE

I agree with this decision for the following reasons: 1. SIP and PyQt are both maintained upstream and function perfectly with Trinity as-is; it makes no sense to maintain a Trinity-specific copy of these software projects. 2. PyKDE needs to be patched for Trinity, and has already been moved to <svnroot>/libraries/python-kde3 3. This decision seems to fit with the general user-configurability model of Trinity; some users may want to install the Java/Ruby bindings, but not the Python bindings.

With this in mind, I believe the correct course of action is to remove the <svnroot>/kdebindings/python folder completely.

Tim