Talk:Installing third party softwares in terminal/Build/KDE4: Difference between revisions
(Excluding Qt examples from building) |
Praneethu.u (talk | contribs) m (moved Talk:Getting Started/Build/KDE4 to Talk:Installing third party softwares in terminal/Build/KDE4: I want to know how to install a 3rd party software , which doesn't have 1-click install. eg. i downloaded pidgin and extracted it. later in ) |
||
(110 intermediate revisions by 24 users not shown) | |||
Line 1: | Line 1: | ||
== ~/install == | ==== This article is fat ==== | ||
When I first wrote this article, it was lean and mean and simple to understand. And it was good for all distributions. Now I have the impression of a fat pig when I read this article. I pledge for removing the usual sources of error, e.g. the many subdirectories. Why do we need a directory KDE, for example ? | |||
If a tutorial is not simple, it is not done. | |||
--[[User:Tstaerk|Tstaerk]] 14:23, 9 September 2007 (CEST) | |||
:+1. A cleanup would be nice, especially before the official 4.0.0 release! Volunteers needed who do this. --[[User:Dhaumann|Dhaumann]] 22:52, 9 September 2007 (CEST) | |||
:This tutorial is fine by me. Okay, that's not for newbies, but someone who wants to compile KDE4 RC1 needs to know how to follow this tutorial at least. --[[User:Chackal_sjc|Chackal_sjc]] 06:56, 27 November 2007 (CEST) | |||
==== This article is full of errors ==== | |||
For example it *is* nessecary to install qt-copy, even if you keep it in the source directory (which leads to 394583069845 error messages on the console during the install). And kdelibs won't build unless something unknown is done with strigi - if it is installed into KDEDIR, it isn't just found. | |||
the heading says pre-requirments are to read "Anonymous SVN Quickstart Guide" first. but the things it does are mostly done in this guide(but a little differently). for example the "Anonymous SVN Quickstart Guide" has you just svn a bunch of stuff.... but that all ended up in the wrong place cause in this guide the svn'd stuff needed to go to "kde-devl"-user's dir not the normal user dir.. | |||
:This tutorial clearly states: "The rest of this tutorial assumes you are running as the kde-devel user." -[[User:TMG|TMG]] 14:16, 25 June 2007 (CEST) | |||
==== This article is complicated ==== | |||
when I wrote this article, it was lean and simple. It has been improved somewhere, but on most places worsened. An example is the directory structure (to get to qt-copy: cd && cd qt-copy; to get to kdelibs: cs && cd kdelibs; to get to kdepim: cs && cd KDE && cd kdepim - no one understands this!!!). | |||
Another example is cs and cb which is quite unnecessary as my initial article shows. But of course, with the complexity as the article has NOW, it IS necessary. | |||
Why do you spoil a simple article so that even I no longer find my own subdirs ? | |||
--[[User:Tstaerk|Tstaerk]] 10:25, 28 May 2007 (CEST) | |||
: Where do you see "cs && cd KDE && cd kdepim"? Because I don't see that anywhere. In any case it would just be "cs kdepim". Perhaps that's the bit need explaining a bit better? --[[User:Aseigo|Aseigo]] 02:48, 29 May 2007 (CEST) | |||
:To whom are you talking to? ;) There are many contributors and as it's a wiki an article probably "degenerates" automatically if noone has an eye on it. The article certainly has valuable information and simply needs a cleanup. In other words: Fix it! :) --[[User:Dhaumann|Dhaumann]] 12:20, 28 May 2007 (CEST) | |||
::IMHO all of this cs/cb/cmakekde and such is only confusing, users just do copy&paste with no really knowledge of what's going on when they type those commands. This way troubleshooting is quite difficult, and they learn nothing about the '''real''' compiling way. The concept of source/build dirs is barely noted. The ''old'' http://developer.kde.org/build/trunk.html has some more commands to type, but it was quite more understandable and clear about the '''real''' steps to do. --[[user:Pino|pino]] 12:54, 28 May 2007 (CEST) | |||
::: Yes, this article could go back to being more verbose. I suppose what is missing is an explanation of ''why'' the shortcuts are used. They are there for a reason. I also don't get the differentiation between real and not real steps; unless we now consider using the shell for what it was designed for as not real. --[[User:Aseigo|Aseigo]] 02:48, 29 May 2007 (CEST) | |||
:::: What's wrong in explicitely telling: | |||
<pre> | |||
svn co .../kdelibs | |||
mkdir build-kdelibs | |||
cd build-kdelibs | |||
cmake <options> ../kdelibs | |||
make install | |||
</pre> | |||
:::: After all, we did that with the <tt>./configure && make && make install</tt> sequence in KDE 3 times, and that worked quite fine. I still fail why we have to make our things more complicated. Moreover, these macros force fixed paths -- [[user:Pino|pino]] 23:43, 29 May 2007 (CEST) | |||
:I am also for removing cb and cs, somebody should just do it. They are indeed confusing and sometimes don't work as expected (that is why cd $KDE_SRC is needed in one place). cmakekde on the other hand could stay IMHO. -[[User:TMG|TMG]] 14:16, 25 June 2007 (CEST) | |||
:::: I find this article too confusing, more-so than it needs to be | |||
This should be simplified, it should be made much easier to understand, with more technical on info later on. I find it hard to just follow it along. Remember, you guys are trying to help out would-be developers, so there can be more of them (good). With guides like this, and guides that don't exist, the new developers will be overly confused (like me) and will probably turn the other way (bad). I don't know, maybe it's just me that finds it too complex to understand.... | |||
==== Q: What is cs and cb? ==== | |||
A: '''This is not a typo'''. Read the [http://techbase.kde.org/index.php?title=Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc article about setting up your .bashrc]. Both '''cs''' and '''cb''' are bash functions, used to change to the KDE source directory and KDE build directory respectively. | |||
==== Q: Are there build instructions for other OS? ==== | |||
A: Actually '''yes''', for [[Getting Started/Build/KDE4/Mac OS X|Mac OS X]]. There also is [http://www.kdelibs.com kdelibs.com] (see also [[User_talk:Jstaniek#KDElibs.com_and_developernew.kde.org_coexistence|here]]) which will be merged into this wiki in the future. | |||
==== Q: Isn't the install prefix, make and make install missing for modules like kdelibs and kdebase? ==== | |||
A: No. The shell function ''cmakekde'' handles this, have a look at the file [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|.bashrc]]. | |||
==== Notes: ~/install ==== | |||
When installing KDE4, I strongly recommend installing all tools (like dbus and cmake) and kde packages into the same place, e.g. ~/install. Qt is the only exception. | When installing KDE4, I strongly recommend installing all tools (like dbus and cmake) and kde packages into the same place, e.g. ~/install. Qt is the only exception. | ||
Line 11: | Line 73: | ||
You may not experience any problems when installed like I advise not to, however I have and you might too in some typical situations. | You may not experience any problems when installed like I advise not to, however I have and you might too in some typical situations. | ||
==== Install CMake modules local ==== | |||
The CMake modules should be installed local into ~/install/cmake/modules or similar. | |||
When following the current instructions [[ Getting_Started/Build/KDE4#Install_additional_CMake_modules|6.1: Install additional CMake modules]], it's impossible to do a non-root installation, because "kdelibs/cmake/modules/cmake_install.cmake" wants to install the modules to "/cmake/modules". (I didn't install CMake local, because my system already provided CMake > 2.4.3). | |||
I've already tried to do this, fiddling around with CMAKE_MODULE_PATH and DATA_INSTALL_DIR but couldn't get it working. | |||
Does anybody know how to do this properly? | |||
--[[User:Eliasp|Eliasp]] 15:44, 4 January 2007 (CET) | |||
==== Fixes needed ==== | |||
* qt-copy: Should we pass the -debug flag? Doesn't Qt install debug information separately by default anyways? Or is that just in the snapshot? --[[User:Mpyne|Mpyne]] | |||
: according to ./configure --help, the default is -release in snapshot. --[[User:Aseigo|Aseigo]] 04:33, 14 March 2007 (CET) | |||
* In the part of the tutorial that describes how to create a new users, shoudn't to have an edit /etc/sudoers to add permitions for kde-devel call sudo? --[[User:SilveiraNeto|SilveiraNeto]] 03:01, 14 March 2007 (CET) | |||
: no. why would you want them to have sudo access? | |||
==== libungif/giflib ==== | |||
Since the patents expired, why not use giflib? | |||
==== Old gcc and -pch flag ==== | |||
In Qt part I had problems with error like this: [http://www.qtforum.org/thread.php?threadid=19998 QtForum thread]. I had GCC 3.3.X installed. Using -pch flag (as in recipe) get me errors. Someone friendly gave me tip on #kde-devel not to use this flag, although I didn't test it. Instead I've just updated gcc and g++ from debian repositories. Newer version works fine as "Precompiled headers are supported in GCC (3.4 and newer)" [http://en.wikipedia.org/wiki/Precompiled_header Wikipedia pch]. | |||
==== Build status ==== | |||
You might want to include the [http://developer.kde.org/~dirk/dashboard/ dashboard link] to show which modules currently build and which don't. --[[User:141.35.8.106|141.35.8.106]] 13:28, 20 March 2007 (CET) | |||
== Extra optional software == | |||
- openldap | |||
- cyrus | |||
If there was a line at the top like: | |||
sudo apt-get install libaaa-dev libbbb-dev ...-dev ... | |||
This would be very useful and save hours. Is this something we should do? | |||
== su - kde4 didn't set the variables == | |||
after running 'su - kde4' and 'export' i saw that no variables in .bashrc were set, instead the old one (of the system) where set. I tried 'su kde4' and it worked fine. Why is that? | |||
I'm running gentoo 2006.1 amd64 | |||
== Qt Flags == | |||
Are "-pch" and "-qdbus" really needed? The configure script shows that they're enabled by default. --[[User:McEnroe|McEnroe]] 16:49, 19 April 2007 (CEST) | |||
:Fixed. Also got rid of openssl for the same reason [[User:Logixoul|Logixoul]] 18:03, 5 July 2007 (CEST) | |||
== Amount of space needed? == | |||
It would be nice to know how much space (roughly, in GB) you need for a setup to build and run the basic things and packages. --[[User:Liquidat|Liquidat]] 03:08, 7 June 2007 (CEST) | |||
: 4.5 GB --[[User:Logixoul|Logixoul]] 18:12, 5 July 2007 (CEST) | |||
== Install error? == | |||
With the kdesupport package I have an install error: | |||
<code> | |||
CMake Error: Error in cmake code at | |||
/media/local/kde-devel/kde/build/kdesupport/qca/plugins/qca-logger/cmake_install .cmake:35: | |||
FILE cannot create directory: /usr/lib/qt4/plugins/crypto. Maybe need administrative privileges. | |||
Current CMake stack: /media/local/kde-devel/kde/build/kdesupport/cmake_install.c make;/media/local/kde-devel/kde/build/kdesupport/qca/cmake_install.cmake;/media/ local/kde-devel/kde/build/kdesupport/qca/plugins/cmake_install.cmake;/media/loca l/kde-devel/kde/build/kdesupport/qca/plugins/qca-logger/cmake_install.cmake | |||
make: *** [install] Error 255 | |||
</code> | |||
Why is it trying to install that system wide? | |||
:Have you installed local copy of qt4 as described in this tutorial? I had the same error while trying to skip installation of local qt4 copy and use system-wide installed one. The error is gone with local copy of qt4. | |||
::I checked back, and the problem is that the script tries to install "libqca-logger.so" to $QTDIR - any idea how to change that? | |||
:::Did you set $QTDIR to the correct value? Make sure you use the .bashrc so that all environment variables are correct. -[[User:TMG|TMG]] 14:25, 25 June 2007 (CEST) | |||
::::The entire point is that $QTDIR has to be set to /usr/lib/qt4/ - because I use the system wide installed copy of Qt 4.3! | |||
::::So the problem is not that $QTDIR is set wrong but that the script tries to install something to $QTDIR. --[[User:141.35.185.149|141.35.185.149]] 23:38, 3 July 2007 (CEST) | |||
:::::Well, then you probably need to install with sudo to get the file installed. I guess it needs to be in the Qt directory because otherwise, Qt doesn't find the files. -[[User:TMG|TMG]] 17:31, 4 July 2007 (CEST) | |||
== Wrong line numbers (and explanation) in the "What's Happening" section for Qt part. == | |||
Line numbers: | |||
---- | |||
Once the patches have been applied, we then set up the build using the configure script (line 5-7). Finally, we build the minimal requirements for KDE (line 8)... | |||
---- | |||
It should be 5-6 for configure and 7 for make. | |||
Explanation is wrong because there is no make install command. And this directory will be used directly. But in the article: "...we build the minimal requirements for KDE (line 8) and install (line 9-10) Qt". | |||
But in lines 9-10: | |||
---- | |||
# if we don't install, we'll just clear obj files to | |||
# save disk space | |||
---- | |||
Best regards, powerfox. | |||
== Wrong directories? == | |||
Why does the recipe for kdesupport only say "cs" before getting the source and building while the "cmakekdeall" function in the example .bashrc says "cs KDE/kdesupport && svn up && cmakekde"? | |||
It should either use the KDE subfolder or it shouldn't but now I'm confused as to which of the two is right. | |||
== Problem with required soprano version (Kubuntu Gutsy Gibbon) == | |||
(sorry for grammar errors if they occur) | |||
So, | |||
I,m using Kubuntu Gutsy Gibbon and I had problems with soprano library at installing kdelibs. | |||
cmakekde requires to install kdelibs the version of soprano library, which does not exist in ubuntu repositories. The needed version you can find e.g. | |||
here: http://ubuntu2.cica.es/ubuntu/ubuntu/pool/universe/s/soprano/ | |||
From this website you have to download libsoprano-dev and libsoprano4 having the same suffix (e.g. ubuntu1~gutsy1_all.deb if you are using Kubuntu Gutsy Gibbon). | |||
Go to directory where you downloaded packages and install each package using dpkg ( I have forgotten the order, so try and when something goes wrong, dpkg shows an information and proposes a solution). | |||
After this remove ~/kde/build/KDE/kdelibs/CMakeCache.txt and try again to install kdelibs. | |||
Good luck :) | |||
* It was damned hard to find, but libsoprano-dev in Gutsy is 1.96.0, and kdelibs requires >=1.97.1. The article says "in this case you need to download and build the relevant part of kdesupport", but as long as the package is installed, cmakekde prefers the files in /usr/include to those under ~/kde/include. Only after removing the package, I was able to move forward. | |||
* I think the real fix should be to make cmakekde prefer the local versions of include files and libraries, but until then, we should at least fix the procedure for Gutsy - please remove libsoprano-dev from the list of packages to install. | |||
* Thanks, Shai. 19:53, 28 November 2007 (CET) | |||
* kdelibs requires Soprano >=1.99 --> Build kdesupport and remove package libsoprano-dev and libsoprano4 : make all folks - chatmoa - 11Dec2007 | |||
== Following the article I get directly into "no objdir found. Tried /home/kde4/kde/build/qt-copy" == | |||
Following the article I get to (in order): | |||
-modify the .bashrc file with the one provided (which has a wrong "export QTDIR=$HOME/qt-copy") when everything else in the article uses "~/kde/src/qt-copy" or "~/kde/build/qt-copy" (I don't really understand which, but sure not "~/qt-copy" | |||
-go to the console and do: | |||
cs | |||
svn checkout svn://anonsvn.kde.org/home/kde/trunk/qt-copy | |||
cd qt-copy | |||
./apply_patches | |||
cb | |||
../../src/qt-copy/configure -largefile -phonon -qt-gif -openssl -opengl -glib -prefix $QTDIR | |||
make -j2 | |||
At this point the make says: "no objdir found. Tried /home/kde4/kde/build/qt-copy", which I have no idea what means, but anyway is not an usual message of the "make" command. | |||
Try to follow the article to convince yourself. Also these smart command like cs, cb and the like don't work if they are called from inside a script, and too mysterious, so I would really like the thing a little more verbose and less high level smart shell tricks. | |||
Alex |
Latest revision as of 02:09, 2 February 2011
This article is fat
When I first wrote this article, it was lean and mean and simple to understand. And it was good for all distributions. Now I have the impression of a fat pig when I read this article. I pledge for removing the usual sources of error, e.g. the many subdirectories. Why do we need a directory KDE, for example ? If a tutorial is not simple, it is not done.
--Tstaerk 14:23, 9 September 2007 (CEST)
- +1. A cleanup would be nice, especially before the official 4.0.0 release! Volunteers needed who do this. --Dhaumann 22:52, 9 September 2007 (CEST)
- This tutorial is fine by me. Okay, that's not for newbies, but someone who wants to compile KDE4 RC1 needs to know how to follow this tutorial at least. --Chackal_sjc 06:56, 27 November 2007 (CEST)
This article is full of errors
For example it *is* nessecary to install qt-copy, even if you keep it in the source directory (which leads to 394583069845 error messages on the console during the install). And kdelibs won't build unless something unknown is done with strigi - if it is installed into KDEDIR, it isn't just found.
the heading says pre-requirments are to read "Anonymous SVN Quickstart Guide" first. but the things it does are mostly done in this guide(but a little differently). for example the "Anonymous SVN Quickstart Guide" has you just svn a bunch of stuff.... but that all ended up in the wrong place cause in this guide the svn'd stuff needed to go to "kde-devl"-user's dir not the normal user dir..
- This tutorial clearly states: "The rest of this tutorial assumes you are running as the kde-devel user." -TMG 14:16, 25 June 2007 (CEST)
This article is complicated
when I wrote this article, it was lean and simple. It has been improved somewhere, but on most places worsened. An example is the directory structure (to get to qt-copy: cd && cd qt-copy; to get to kdelibs: cs && cd kdelibs; to get to kdepim: cs && cd KDE && cd kdepim - no one understands this!!!). Another example is cs and cb which is quite unnecessary as my initial article shows. But of course, with the complexity as the article has NOW, it IS necessary.
Why do you spoil a simple article so that even I no longer find my own subdirs ? --Tstaerk 10:25, 28 May 2007 (CEST)
- Where do you see "cs && cd KDE && cd kdepim"? Because I don't see that anywhere. In any case it would just be "cs kdepim". Perhaps that's the bit need explaining a bit better? --Aseigo 02:48, 29 May 2007 (CEST)
- To whom are you talking to? ;) There are many contributors and as it's a wiki an article probably "degenerates" automatically if noone has an eye on it. The article certainly has valuable information and simply needs a cleanup. In other words: Fix it! :) --Dhaumann 12:20, 28 May 2007 (CEST)
- IMHO all of this cs/cb/cmakekde and such is only confusing, users just do copy&paste with no really knowledge of what's going on when they type those commands. This way troubleshooting is quite difficult, and they learn nothing about the real compiling way. The concept of source/build dirs is barely noted. The old http://developer.kde.org/build/trunk.html has some more commands to type, but it was quite more understandable and clear about the real steps to do. --pino 12:54, 28 May 2007 (CEST)
- Yes, this article could go back to being more verbose. I suppose what is missing is an explanation of why the shortcuts are used. They are there for a reason. I also don't get the differentiation between real and not real steps; unless we now consider using the shell for what it was designed for as not real. --Aseigo 02:48, 29 May 2007 (CEST)
- What's wrong in explicitely telling:
svn co .../kdelibs mkdir build-kdelibs cd build-kdelibs cmake <options> ../kdelibs make install
- After all, we did that with the ./configure && make && make install sequence in KDE 3 times, and that worked quite fine. I still fail why we have to make our things more complicated. Moreover, these macros force fixed paths -- pino 23:43, 29 May 2007 (CEST)
- I am also for removing cb and cs, somebody should just do it. They are indeed confusing and sometimes don't work as expected (that is why cd $KDE_SRC is needed in one place). cmakekde on the other hand could stay IMHO. -TMG 14:16, 25 June 2007 (CEST)
- I find this article too confusing, more-so than it needs to be
This should be simplified, it should be made much easier to understand, with more technical on info later on. I find it hard to just follow it along. Remember, you guys are trying to help out would-be developers, so there can be more of them (good). With guides like this, and guides that don't exist, the new developers will be overly confused (like me) and will probably turn the other way (bad). I don't know, maybe it's just me that finds it too complex to understand....
Q: What is cs and cb?
A: This is not a typo. Read the article about setting up your .bashrc. Both cs and cb are bash functions, used to change to the KDE source directory and KDE build directory respectively.
Q: Are there build instructions for other OS?
A: Actually yes, for Mac OS X. There also is kdelibs.com (see also here) which will be merged into this wiki in the future.
Q: Isn't the install prefix, make and make install missing for modules like kdelibs and kdebase?
A: No. The shell function cmakekde handles this, have a look at the file .bashrc.
Notes: ~/install
When installing KDE4, I strongly recommend installing all tools (like dbus and cmake) and kde packages into the same place, e.g. ~/install. Qt is the only exception.
The reason for this is because if you install some packages to ~/kde and some to /usr/local and maybe one in /usr then cmake will generate errors like:
-- It is impossible to order the include directories.
This is not a fatal error, so you will still be able to compile, but you will possibly be using the wrong versions of libraries and this will product problems that are very hard to diagnose.
You may not experience any problems when installed like I advise not to, however I have and you might too in some typical situations.
Install CMake modules local
The CMake modules should be installed local into ~/install/cmake/modules or similar. When following the current instructions 6.1: Install additional CMake modules, it's impossible to do a non-root installation, because "kdelibs/cmake/modules/cmake_install.cmake" wants to install the modules to "/cmake/modules". (I didn't install CMake local, because my system already provided CMake > 2.4.3).
I've already tried to do this, fiddling around with CMAKE_MODULE_PATH and DATA_INSTALL_DIR but couldn't get it working.
Does anybody know how to do this properly?
--Eliasp 15:44, 4 January 2007 (CET)
Fixes needed
- qt-copy: Should we pass the -debug flag? Doesn't Qt install debug information separately by default anyways? Or is that just in the snapshot? --Mpyne
- according to ./configure --help, the default is -release in snapshot. --Aseigo 04:33, 14 March 2007 (CET)
- In the part of the tutorial that describes how to create a new users, shoudn't to have an edit /etc/sudoers to add permitions for kde-devel call sudo? --SilveiraNeto 03:01, 14 March 2007 (CET)
- no. why would you want them to have sudo access?
libungif/giflib
Since the patents expired, why not use giflib?
Old gcc and -pch flag
In Qt part I had problems with error like this: QtForum thread. I had GCC 3.3.X installed. Using -pch flag (as in recipe) get me errors. Someone friendly gave me tip on #kde-devel not to use this flag, although I didn't test it. Instead I've just updated gcc and g++ from debian repositories. Newer version works fine as "Precompiled headers are supported in GCC (3.4 and newer)" Wikipedia pch.
Build status
You might want to include the dashboard link to show which modules currently build and which don't. --141.35.8.106 13:28, 20 March 2007 (CET)
Extra optional software
- openldap - cyrus
If there was a line at the top like:
sudo apt-get install libaaa-dev libbbb-dev ...-dev ...
This would be very useful and save hours. Is this something we should do?
su - kde4 didn't set the variables
after running 'su - kde4' and 'export' i saw that no variables in .bashrc were set, instead the old one (of the system) where set. I tried 'su kde4' and it worked fine. Why is that?
I'm running gentoo 2006.1 amd64
Qt Flags
Are "-pch" and "-qdbus" really needed? The configure script shows that they're enabled by default. --McEnroe 16:49, 19 April 2007 (CEST)
- Fixed. Also got rid of openssl for the same reason Logixoul 18:03, 5 July 2007 (CEST)
Amount of space needed?
It would be nice to know how much space (roughly, in GB) you need for a setup to build and run the basic things and packages. --Liquidat 03:08, 7 June 2007 (CEST)
- 4.5 GB --Logixoul 18:12, 5 July 2007 (CEST)
Install error?
With the kdesupport package I have an install error:
CMake Error: Error in cmake code at
/media/local/kde-devel/kde/build/kdesupport/qca/plugins/qca-logger/cmake_install .cmake:35:
FILE cannot create directory: /usr/lib/qt4/plugins/crypto. Maybe need administrative privileges.
Current CMake stack: /media/local/kde-devel/kde/build/kdesupport/cmake_install.c make;/media/local/kde-devel/kde/build/kdesupport/qca/cmake_install.cmake;/media/ local/kde-devel/kde/build/kdesupport/qca/plugins/cmake_install.cmake;/media/loca l/kde-devel/kde/build/kdesupport/qca/plugins/qca-logger/cmake_install.cmake
make: *** [install] Error 255
Why is it trying to install that system wide?
- Have you installed local copy of qt4 as described in this tutorial? I had the same error while trying to skip installation of local qt4 copy and use system-wide installed one. The error is gone with local copy of qt4.
- I checked back, and the problem is that the script tries to install "libqca-logger.so" to $QTDIR - any idea how to change that?
- Did you set $QTDIR to the correct value? Make sure you use the .bashrc so that all environment variables are correct. -TMG 14:25, 25 June 2007 (CEST)
- The entire point is that $QTDIR has to be set to /usr/lib/qt4/ - because I use the system wide installed copy of Qt 4.3!
- So the problem is not that $QTDIR is set wrong but that the script tries to install something to $QTDIR. --141.35.185.149 23:38, 3 July 2007 (CEST)
- Well, then you probably need to install with sudo to get the file installed. I guess it needs to be in the Qt directory because otherwise, Qt doesn't find the files. -TMG 17:31, 4 July 2007 (CEST)
- Did you set $QTDIR to the correct value? Make sure you use the .bashrc so that all environment variables are correct. -TMG 14:25, 25 June 2007 (CEST)
Wrong line numbers (and explanation) in the "What's Happening" section for Qt part.
Line numbers:
Once the patches have been applied, we then set up the build using the configure script (line 5-7). Finally, we build the minimal requirements for KDE (line 8)...
It should be 5-6 for configure and 7 for make.
Explanation is wrong because there is no make install command. And this directory will be used directly. But in the article: "...we build the minimal requirements for KDE (line 8) and install (line 9-10) Qt". But in lines 9-10:
- if we don't install, we'll just clear obj files to
- save disk space
Best regards, powerfox.
Wrong directories?
Why does the recipe for kdesupport only say "cs" before getting the source and building while the "cmakekdeall" function in the example .bashrc says "cs KDE/kdesupport && svn up && cmakekde"?
It should either use the KDE subfolder or it shouldn't but now I'm confused as to which of the two is right.
Problem with required soprano version (Kubuntu Gutsy Gibbon)
(sorry for grammar errors if they occur) So,
I,m using Kubuntu Gutsy Gibbon and I had problems with soprano library at installing kdelibs.
cmakekde requires to install kdelibs the version of soprano library, which does not exist in ubuntu repositories. The needed version you can find e.g. here: http://ubuntu2.cica.es/ubuntu/ubuntu/pool/universe/s/soprano/
From this website you have to download libsoprano-dev and libsoprano4 having the same suffix (e.g. ubuntu1~gutsy1_all.deb if you are using Kubuntu Gutsy Gibbon).
Go to directory where you downloaded packages and install each package using dpkg ( I have forgotten the order, so try and when something goes wrong, dpkg shows an information and proposes a solution).
After this remove ~/kde/build/KDE/kdelibs/CMakeCache.txt and try again to install kdelibs.
Good luck :)
- It was damned hard to find, but libsoprano-dev in Gutsy is 1.96.0, and kdelibs requires >=1.97.1. The article says "in this case you need to download and build the relevant part of kdesupport", but as long as the package is installed, cmakekde prefers the files in /usr/include to those under ~/kde/include. Only after removing the package, I was able to move forward.
- I think the real fix should be to make cmakekde prefer the local versions of include files and libraries, but until then, we should at least fix the procedure for Gutsy - please remove libsoprano-dev from the list of packages to install.
- Thanks, Shai. 19:53, 28 November 2007 (CET)
- kdelibs requires Soprano >=1.99 --> Build kdesupport and remove package libsoprano-dev and libsoprano4 : make all folks - chatmoa - 11Dec2007
Following the article I get directly into "no objdir found. Tried /home/kde4/kde/build/qt-copy"
Following the article I get to (in order):
-modify the .bashrc file with the one provided (which has a wrong "export QTDIR=$HOME/qt-copy") when everything else in the article uses "~/kde/src/qt-copy" or "~/kde/build/qt-copy" (I don't really understand which, but sure not "~/qt-copy"
-go to the console and do:
cs
svn checkout svn://anonsvn.kde.org/home/kde/trunk/qt-copy
cd qt-copy
./apply_patches
cb
../../src/qt-copy/configure -largefile -phonon -qt-gif -openssl -opengl -glib -prefix $QTDIR
make -j2
At this point the make says: "no objdir found. Tried /home/kde4/kde/build/qt-copy", which I have no idea what means, but anyway is not an usual message of the "make" command.
Try to follow the article to convince yourself. Also these smart command like cs, cb and the like don't work if they are called from inside a script, and too mysterious, so I would really like the thing a little more verbose and less high level smart shell tricks. Alex