This is what I found when debugging Cmake problems when building kdebase.
[castro@castro2 kdebase]$ grep -r "WITH_XCOMPOSITE" *
CMakeLists.txt:option( WITH_XCOMPOSITE "Enable xcomposite support" OFF )
**** kicker/taskmanager compiles OK with or without XCOMPOSITE.
kicker/taskmanager/CMakeLists.txt:if( WITH_XCOMPOSITE )
kicker/taskmanager/CMakeLists.txt:endif( WITH_XCOMPOSITE )
**** kwin/kompmgr does not compile with or without XCOMPOSITE.
Looking into kompmgr.c shows that it requires XCOMPOSITE
#include <X11/extensions/Xcomposite.h>
#include <X11/extensions/Xdamage.h>
#include <X11/extensions/Xrender.h>
#include <X11/extensions/shape.h>
The question is should we have the option (WITH_XCOMPOSITE) in
kompmgr/CMakeLists.txt.
kwin/kompmgr/CMakeLists.txt:if( WITH_XCOMPOSITE )
kwin/kompmgr/CMakeLists.txt:endif( WITH_XCOMPOSITE )
If the answer is YES then should try and build it?
Looking into kwin/kompmgr/configure.in.in
if test "x$with_composite" != "xno"; then
KDE_CHECK_HEADERS(X11/extensions/Xdamage.h,,compile_kompmgr=no,[#include
<X11/Xlib.h>])
KDE_CHECK_HEADERS(X11/extensions/Xcomposite.h,,compile_kompmgr=no,[#include
<X11/Xlib.h>])
KDE_CHECK_HEADERS(X11/extensions/Xrender.h,,compile_kompmgr=no,[#include
<X11/Xlib.h>])
else
compile_kompmgr=no
fi
it shows us that we should NOT build it.
kwin/CMakeLists.txt: if( WITH_XCOMPOSITE )
add_subdirectory( kompmgr )
kwin/CMakeLists.txt: endif( WITH_XCOMPOSITE )
[castro@castro2 kdebase]$
The changes I have made to kwin/kompmgr/CMakeLists.txt are quick & dirty,
but it works for now.
I will put some more thought to it in the next few days.
Castro.
Hi serghei,
Hi all,
Please accept the slopy cut & past in my last posting.
kdebase now compiles 100% without errors. :-)
The last fix is to kdebase/ksplashml/themeengine/simple/CmakeLists.txt
I added this
link_directories(
${TQT_LIBRARY_DIRS}
)
before this
##### ksplashsimple (executable) ################
Is it only archlinux that is showing these problemes?
Castro.
I found some patches that I think have not been merged into svn.
What is the best way for me to check whether a patch has already been merged into svn? Is there a smart/efficient/programmtic way to do this?
Thanks.
Darrell
I made some progress with building PyKDE3. I had to cheat. I think.
The problem seems to be that building Trinity to install in /opt/trinity confuses the PyKDE3 build process. Last autumn when I built Trinity 3.5.12 to install in /usr I had no problems building PyKDE3.
Since then I have not tried to build any packages to install in /usr. I have been focusing on installing in /opt/trinity in order to coexist with KDE4/QT4.
When Trinity is installed in /opt/trinity the build always fails with this kind of error:
=========================================
/usr/bin/ld: cannot find -lDCOP
collect2: ld returned 1 exit status
make[1]: *** [dcop.so] Error 1
make[1]: Leaving directory `/dev/shm/PyKDE-3.16.7/dcop'
make: *** [all] Error 2
=========================================
I then create a sym link in /usr/lib to the allegedly not found library:
ln -s /opt/trinity/lib/libDCOP.so libDCOP.so
The next build proceeds past that error but again fails with a similar not found error message about the next module, kdecore.
I create another sym link. The package proceeds to build to the next module, kdefx, and again fails.
Rinse. Repeat. For each module:
dcop kdecore kdefx kdeui kio kresources kabc kutils kfile kparts khtml kspell kdeprint kmdi
I modified my build script to temporarily create the sym links on-the-fly and remove them after make completes.
The package then builds without failure. Yet I wonder whether this will break the package libraries. Are they linked to /usr/lib rather than /opt/trinity/lib?
Seems something in the PyKDE3 configuration is hard-coded to /usr/lib. I already have the following in my build script:
sed -i -e "s:/usr:${PREFIX}:" configure.py
where $PREFIX is /opt/trinity
/etc/ld.so.conf contains /opt/trinity/lib, which was inserted from the kdelib package (and runs ldconfig, but I have run ldconfig manually too). Running ldconfig -v shows the allegedly not found libraries in /opt/trinity/lib.
The build script configure output says the following:
KDE base directory is /opt/trinity
KDE include directory is /opt/trinity/include
KDE lib directory is /opt/trinity/lib/kde3
lib directory is /opt/trinity/lib
Everything seems to indicate the libraries should be found. Yet the package refuses to build without the temporary sym links. Seems make should find the libraries in /opt/trinity/lib.
Exporting LD_LIBRARY_PATH in the build script does not help.
Any ideas what is happening? Any ideas how to fix?
Darrell
I notice in the Amarok CMakeLists.txt there are several missing build options that were available in automake:
--with-libnjb
--with-libmtp
--with-libkarma
--with-mp4v2
--without-musicbrainz
--without-daap
--disable-amazon
For myself I have no need for syncing to devices or sharing music. Would be nice to build Amarok without that overhead. :)
I realize a lot of work is going on with everything. I thought I'd mention this and hopefully the options are added eventually.
Thanks.
Darrell
Tim,
I am able to build all of the same 3.5.12 packages I built last autumn except PyKDE3, Digikam, and Gwenview. I already submitted a post about PyKDE3 (help is appreciated!).
The primary difference this time that the builds are failing is I am trying to install the Trinity/KDE packages into /opt/trinity rather than /usr. Some library and support packages, such as sip, PyQT3, PyKDE3, libical, libcaldav, etc., I am still installing in /usr and /usr/lib.
Digikam FTBFS with this error:
====================
grep: /usr/lib/libkdecore.la: No such file or directory
/usr/bin/sed: can't read /usr/lib/libkdecore.la: No such file or directory
libtool: link: `/usr/lib/libkdecore.la' is not a valid libtool archive
====================
Gwenview FTBFS with this error:
====================
grep: /usr/lib/libkio.la: No such file or directory
/usr/bin/sed: can't read /usr/lib/libkio.la: No such file or directory
libtool: link: `/usr/lib/libkio.la' is not a valid libtool archive
====================
Notice the builds are trying to find those files in /usr/lib rather than /opt/trinity/lib. Something in the configuration files is hard-coded to /usr/lib.
I realize 3.5.12 is more or less etched in stone, but the cmake conversion will take time. All I need is a patch that I can merge on-the-fly in my build scripts to ensure automake looks in the correct location. Besides, neither of these packages have been converted to cmake yet and probably won't be for some time.
Maybe the problem is an environment variable, although all of the other packages compiled fine.
I want to get all of these 3.5.12 packages to build in Slackware 12.2 with /opt/trinity. Once proven they will build, install, and run there I then will start the testing the build process with the next Slackware release, which are required to get installed in a location other than /usr. This is very much proof of concept before moving to the next step. Not to mention that in the next step I need to build qt3 too.
Should anyone start quashing bugs with the core or main suite packages I can rebuild Trinity packages in 12.2 and test those patches immediately. I also should be able to install Trinity 3.5.12 alongside KDE 3.5.10 in 12.2, which will help all of us with troubleshooting and comparisons to KDE3.
Thanks much!
Darrell
Hi Serghei,
I am learning something about Cmake. :-)
I've added few files to your cmake modules.
FindXcomposite.cmake
FindXFixes.cmake
FindXrender.cmake
FindXdamage.cmake
FindXinerama.cmake
This one should be simple but I have run out of steam. :-(
Started work at 2am, it is 5pm!
Time for a pint or two. :-)
[ 81%] Built target ksplashredmond-module
Linking CXX executable ksplashsimple
/usr/bin/ld: cannot find -ltqt
/usr/bin/ld: cannot find -lqt-mt
collect2: ld returned 1 exit status
make[2]: *** [ksplashml/themeengine/simple/ksplashsimple] Error 1
make[1]: ***
[ksplashml/themeengine/simple/CMakeFiles/ksplashsimple.dir/all] Error 2
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
[castro@castro2 trinity-kdebase]$
Castro.
I am having the following problem:
[ 55%] Building CXX object
ksplashml/themeengine/simple/CMakeFiles/ksplashsimple.dir/main.cpp.o
Linking CXX executable ksplashsimple
/usr/bin/ld: cannot find -ltqt
/usr/bin/ld: cannot find -lqt-mt
collect2: ld returned 1 exit status
make[2]: *** [ksplashml/themeengine/simple/ksplashsimple] Error 1
make[1]: *** [ksplashml/themeengine/simple/CMakeFiles/ksplashsimple.dir/all]
Error 2
make[1]: *** Waiting for unfinished jobs....
[ 55%] Building CXX object
ksmserver/CMakeFiles/kdeinit_ksmserver-shared.dir/shutdown.cpp.o
[ 55%] Building CXX object
ksmserver/CMakeFiles/kdeinit_ksmserver-shared.dir/client.cpp.o
[ 56%] Building CXX object
ksmserver/CMakeFiles/kdeinit_ksmserver-shared.dir/KSMServerInterface_skel.cpp.o
[ 56%] Building CXX object
ksmserver/CMakeFiles/kdeinit_ksmserver-shared.dir/server_skel.cpp.o
[ 56%] Building CXX object
ksmserver/CMakeFiles/kdeinit_ksmserver-shared.dir/timed.cpp.o
Linking CXX shared library libkdeinit_ksmserver.so
[ 56%] Built target kdeinit_ksmserver-shared
make: *** [all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
Build failed, check /home/build/scrat/build
make: *** [KDEBASE] Error 1
I don't understand why this is failing here as other modules are not failing.
The patched qt3 is install and so is tqtinterface, the packages that contain
the libarayies in question.
I have looked at the CmakeLists.txt for serveral modules and compared them to
the one in ksplashsimple and I don't see anything that would cause this
error. Since I don't know cmake I am stuck at this time.
Where is this set ie ${TQT_LIBRARY_DIRS}
link_directories(
${TQT_LIBRARY_DIRS}
)
If anyone could point me in the right direction and maybe explain about how
cmake finds libaries I would be grateful. I want to learn this in case of
future problems. I am going to purchase a book on cmake in the future when
I get the money to do so.
Thanks
