Tim,
I traced the build failure to a Debian patch from Debian bug report 357775. The specific patch is 11_fix_get_libdir_name.diff, which can be viewed here, about midpoint in the page:
http://lists.alioth.debian.org/pipermail/pkg-kde-commits/2006-June/003702.h…
I reversed the patch and then was able to build on 64-bit. Ignoring obvious file size differences, my 64-bit package looks exactly the same as my 32-bit package.
In my patch I added some informational text to help debugging because the specific build failure message appears in three different locations. Here is my proposed patch:
===========================================================
diff -urN pytdeextensions/setup.py pytdeextensions.new/setup.py
--- pytdeextensions/setup.py 2012-05-27 17:59:26.000000000 -0500
+++ pytdeextensions.new/setup.py 2012-06-13 20:12:18.000000000 -0500
@@ -135,7 +135,7 @@
if self.clib!=None:
self.clib = glob.glob(os.path.join(self.clib,'libgcc*.a'))[0]
if self.clib is None:
- raise SystemExit, "Failed to find a suitable libgcc library"
+ raise SystemExit, "setup.py: Failed to find a suitable libgcc library"
self.announce("Using %s for clib" % self.clib)
# Make a list of places to look for python .so modules
diff -urN pytdeextensions/src/kdedistutils.py pytdeextensions.new/src/kdedistutils.py
--- pytdeextensions/src/kdedistutils.py 2012-06-13 11:01:28.000000000 -0500
+++ pytdeextensions.new/src/kdedistutils.py 2012-06-13 20:17:43.000000000 -0500
@@ -660,7 +660,7 @@
if self.clib!=None:
self.clib = glob.glob(os.path.join(self.clib,'libgcc*.a'))[0]
if self.clib is None:
- raise SystemExit, "Failed to find a suitable libgcc library"
+ raise SystemExit, "kdedistutils.py (1): Failed to find a suitable libgcc library"
self.announce("Using %s for clib" % self.clib)
# Make a list of places to look for python .so modules
@@ -1591,7 +1591,7 @@
if self.clib!=None:
self.clib = glob.glob(os.path.join(self.clib,'libgcc*.a'))[0]
if self.clib is None:
- raise SystemExit, "Failed to find a suitable libgcc library"
+ raise SystemExit, "kdedistutils.py (2): Failed to find a suitable libgcc library"
self.announce("Using %s for clib" % self.clib)
# Make a list of places to look for python .so modules
@@ -2229,7 +2229,7 @@
###########################################################################
def get_libdir_name():
- #if os.uname()[4] in ['x86_64','mips64','ppc64','sparc64','s390x']:
- # return 'lib64'
- #else:
+ if os.uname()[4] in ['x86_64','mips64','ppc64','sparc64','s390x']:
+ return 'lib64'
+ else:
return 'lib'
===========================================================
Do you want me to push this patch to GIT or do you want to first run a Debian/Ubuntu test build?
Darrell
I built and installed tde-systemsettings. I can't get the app to run and thus can't validate whether the likely patche set I created is needed. Hopefully the package is not distro-specific and can be installed on Slackware.
Here is a backtrace of systemsettings, when run from the mini cli, built and installed as-is:
[Thread debugging using libthread_db enabled]
[KCrash handler]
#5 0x0805be69 in TQValueList<RowIconView*>::detach (this=0x8c)
at /opt/trinity/include/ntqvaluelist.h:566
#6 0x0805c0b2 in TQValueList<RowIconView*>::operator[] (this=0x8c, i=0)
at /opt/trinity/include/ntqvaluelist.h:540
#7 0x0805b763 in KcmSearch (this=0x80f8b00, moduleViewList=0x80ecbfc,
parent=0x80f86b0, name=0x8065509 "search") at kcmsearch.cpp:31
#8 0x08061610 in MainWindow::buildActions (this=0x80ecb28)
at mainwindow.cpp:129
#9 0x0806271d in MainWindow (this=0x80ecb28, embed=true, menuFile=...,
parent=0x0, name=0x0, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>) at mainwindow.cpp:65
#10 0x080601e5 in main (argc=7, argv=0xbfc48114) at main.cpp:56
Here is a backtrace of systemsettings, when run from the mini cli, built and installed after patching with potential XDG patching (same backtrace, which indicates the lack of patching is not the likely cause):
[Thread debugging using libthread_db enabled]
[KCrash handler]
#5 0x0805be69 in TQValueList<RowIconView*>::detach (this=0x8c)
at /opt/trinity/include/ntqvaluelist.h:566
#6 0x0805c0b2 in TQValueList<RowIconView*>::operator[] (this=0x8c, i=0)
at /opt/trinity/include/ntqvaluelist.h:540
#7 0x0805b763 in KcmSearch (this=0x80f8bd8, moduleViewList=0x80ed07c,
parent=0x80f8788, name=0x8065509 "search") at kcmsearch.cpp:31
#8 0x08061610 in MainWindow::buildActions (this=0x80ecfa8)
at mainwindow.cpp:129
#9 0x0806271d in MainWindow (this=0x80ecfa8, embed=true, menuFile=...,
parent=0x0, name=0x0, __in_chrg=<value optimized out>,
__vtt_parm=<value optimized out>) at mainwindow.cpp:65
#10 0x080601e5 in main (argc=7, argv=0xbff685f4) at main.cpp:56
Darrell
I just updated to the latest nightlies and it seems quite a lot broke
because of it.
What I've seen so far (after logging out & back in):
- Errors about TDE's media manager not running
- This error when trying to run Konqueror:
There was an error loading the module Detailed List View.
The diagnostics is:
Library files for ".la" not found in paths.
- alt+f2, does not allow executing scripts from ~/bin anymore (probably
the PATH variable doesn't get set correctly anymore)
- entering ~ (or clicking the home button in Konqueror) gives this error:
Malformed URL
~
All these things were working correctly with the nightlies as updated
till yesterday.
The previous issues I reported are still there.
Best regards,
Julius
Some time ago we discussed a desire to post at our wiki package-specific information needed for building.
Recently Tim and I ran into an interesting quirk with building on 64-bit. (Thanks Tim!) I decided this information should be in the wiki. If you're curious, the quirk is that for 64-bit, building (T)Qt3 with the following configure option might be needed:
-platform ${PLATFORM}
Where, for 64-bit, ${PLATFORM} == linux-g++-64 rather than linux-g++.
Recent posts by Nix regarding build issues also remind me of this wiki need.
Perhaps the time has arrived that we start accumulating this information for the wiki.
For now, perhaps we share information here in the mail list, which will serve somewhat as a way for providing peer reviews before posting to the wiki.
I'm thinking eventually we have a page for each package, even thos that are quite generic with build configurations. Each wiki page will list no less than minimum build information. For many packages they all will look the same except for the package name. Just cookie-cut information because there is nothing complicated about those packages.
We then move many of our preliminary wiki notes to those package-specific pages.
Currently section 5 of the wiki page is our potential portal to individual package information. We can create links in that section as we create each new wiki page for each package.
All I'm asking for at this point is we start pooling knowledge.
We have a project goal of releasing R14 when ready but are focusing on summer's end. That provides us ample time to assemble this information.
Please help!
Darrell
Tim,
Slackware 13.1
Clean build, previous packages all uninstalled.
I built tqt3, tqtinterface but dbus-tqt fails to build for both 32-bit and 64-bit:
-- checking for one of the modules 'tqt'
CMake Error at cmake/modules/TDEMacros.cmake:23 (message):
#################################################
tmoc is not found!
tqt is correctly installed?
#################################################
From my last full build run a couple of days ago, my dbus-tqt build log shows this:
-- checking for one of the modules 'tqt'
-- tmoc path: /usr/bin/tmoc
-- moc path: /opt/trinity/bin/moc
-- uic path: /opt/trinity/bin/uic
-- tqt-replace path: /usr/bin/tqt-replace
-- Performing Test HAVE_USABLE_TQT
-- Performing Test HAVE_USABLE_TQT - Success
-- Configuring done
I verified that tmoc is installed at /usr/bin/tmoc.
Not sure what changed where, but has to be a recent patch.
Darrell
So my attempted build of kdeaccessibility is failing. The failure is
because of Q_SLOTS: nothing is replacing it with <slots> before
processing by uic, so uic is never putting the slot into the .h file and
compilation is failing.
While tqt-replace fixes this up for projects using CMake, the
corresponding call in am_edit was commented out in July 2010, in this
commit:
commit 4f9a36e2fcee4ecd7adbc3e53c8e6837712c2a35
Author: tpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>
Date: Mon Jul 26 02:04:25 2010 +0000
First attempt at getting TQT integrated...
But even with that commented-out tqt-replace call uncommented, it still
doesn't work. If we look at
kaccessibility/kmouth/wordcompletion/Makefile, we see:
all: docs-am all-am
all-am: Makefile $(LIBRARIES)
LIBRARIES = $(noinst_LIBRARIES)
noinst_LIBRARIES = libwordcompletion.a
libwordcompletion.a: $(libwordcompletion_a_OBJECTS) $(libwordcompletion_a_DEPENDENCIES) $(EXTRA_libwordcompletion_a_DEPENDENCIES)
libwordcompletion_a_OBJECTS = $(libwordcompletion_a_nofinal_OBJECTS)
libwordcompletion_a_OBJECTS = $(libwordcompletion_a_nofinal_OBJECTS)
#libwordcompletion_a_OBJECTS = $(libwordcompletion_a_final_OBJECTS)
libwordcompletion_a_final_OBJECTS = libwordcompletion_a.all_cpp.o
and it is the libwordcompletion_a.all_cpp.o rule that has the
tqt-replace call in it.
Thus, this is only going to work if that line is uncommented *and*
--enable-final is passed in. But the Wiki doesn't mention
--enable-final, only --enable-closure!
Unfortunately that *also* doesn't work, and it becomes obvious why Tim
commented that line out -- it's applying to the .cpp files only, but to
be effective tqt-replace must run over the .ui files, before uic gets to
them.
I don't see how this could possibly ever work. Have people actually
managed to compile the non-cmake parts of Trinity in the last little
while?
If so, what configure flags did you use, and could you send me a copy of
kaccessibility/kmouth/wordcompletion/Makefile.in and
kaccessibility/kmouth/wordcompletion/wordcompletionui.{everything but .o
and .lo} after a build? 'cos I am sore confused.
Ditching this whole nightmare and going to cmake is ever such a good
idea! :)
--
NULL && (void)
While finding and testing the various files in the icon themes that needed branding updates, I noticed a sym link named default.kde pointing to crystalsvg. Seems as long as we are trying to catch various branding issues and avoid potential conflicts with KDE, that the sym link should be renamed to default.tde.
Looks like the following apps need nominal patching:
kile
tde-style-qtcurve
kmymoney
tdepim
tdelibs
tdebindings
tdebase (docbook reference)
tde-i18n (docbook references)
Any objections to patching?
Darrell
Has anybody tested exiting Trinity with different icon sets? The exit status dialog image looks great with the crystalsvg icon set.
When used with other icons set the image is KDE rather than TDE. Oops! :-)
Affected icon sets:
kdeclassic
kids
monochrome
slick
Does anybody know which images the exit status dialog grabs so we can update the images?
E. Liddell --- looks like your wonderful art talents will be needed again!
Darrell
