EnglishTranslate original post with Google Translate
Before compiling anything your will have to set some environment variables and to check you have all the minimal dependencies and their development files available.
If you run a Debian Linux you will need to use the « Sid » or unstable version of the distribution. Any other version may provide obsolete version of many KDE <= 4.4 or trunk dependencies. Decide to upgrade your Debian to « Sid » suppose that you know Debian system and you are able to solve possible problems when upgrading. If you run *Ubuntu you are more up-to-date but you have to be sure you are running the latest version of that distribution. Gentoo users should use the Gentoo’s KDE tutorial as Gentoo is providing very up-to-date final KDE in the unstable ebuild repository as well as trunk (with SVN) ebuild that you can install manually or using a sandbox.
As I’m using a LFS (Linux From Scratch) there’s no problem installing KDE trunk on it but you will have to install several dependencies. LFS 6.7 programs are up to date enough but not BLFS ones (even in trunk). Nevertheless, if you choose to install newer version of BLFS trunk programs BLFS installation instructions are working most of the time (be carefull before applying patches). If you have compilation failure with some dependancies try to search for path or solution with Google. That can be hard to find but a solution exist nearly all the time. If you can’t find some dependancies with BLFS try with CBLFS (a wiki). I will provide in the future compilation and installation instructions for KDE dependancies that are not in LFS, BLFS and CBLFS. Before going further with those instructions you will have to remove (C)BLFS version of Qt 4 as well as all its dependencies.
I don’t know enough other distributions but as far as I know, distributions like OpenSuse, Fedora or Mandriva are considered as well up-to-date and without much problems to compile, so that can also be a good choice.
The following of this document is supposing that you run a Debian system as it’s the one I best know. Nevertheless, this should work as well for *Ubuntu systems without too much adaptations. Anyway package names are mainly the same, then command line don’t change.
Many files need to be edited during the process. You can use the editor you want but the given command lines suppose that « nano » is the used one, and I recommend to use a text editor (not graphic). If don’t have nano install it as root with su -c "apt-get install nano" for Debian user’s or sudo "apt-get install nano".
1. Upgrading your system
Upgrading your whole system is dangerous, so please be extra careful when doing all of this. My advise for best results is to quit any graphical interface, and stop all the services you can, in particular cron and derivatives. To do so, go to first console, login as root and type:
/etc/init.d/cron stop
/etc/init.d/anacron stop
/etc/init.d/fcron stop
/etc/init.d/kdm stop
/etc/init.d/gdm stop
/etc/init.d/xdm stop
You can’t have all of those services running at the same time, so if you copy-paste this you will have some « /etc/init.d/XXX: no such file or directory ». This is not a problem, as this is covering all the case I know, but not your case specifically.
All the commands given here suppose that you have root privileges. If you don’t already have such privileges, use su command or sudo sh if you are an *Ubuntu user. If you’re not running « Sid » you need to upgrade the entire system to it, elsewhere you can go directly to the next chapter of this page. First you need to edit your /etc/apt/sources.list and add the following two lines:
deb ftp://ftp.debian.org/debian/ sid main contrib non-free
deb-src ftp://ftp.debian.org/debian/ sid main contrib non-free
Then you have to upgrade by taping this, but be carefull of what will happen then cause this is dangerous, so I suggest that you prepare a live boot CD, just in case:
apt-get update
apt-get autoremove
apt-get clean
apt-get dist-upgrade
apt-get upgrade
In the order this update your package database, remove automatically non-needed packages, clean the local repository, upgrade the whole distribution and upgrade remaining packages if there is some (just in case, we should not have some).
If you have any error message you should fix what is wrong before rebooting cause you may not be able to boot anymore. Generally upgrading from « Lenny » causes no big problems, but older version require to update to Lenny first as Deb packages provided with « Sid » are sometimes using features that are not supported by older versions. Nevertheless, upgrading problems are common with things like Xorg, KDE and Gnome. If you don’t want the KDE provided by Debian you can easily remove it (see next chapter) before upgrading. If you have problem with Xorg when doing dist-upgrade, try apt-get install xserver-xorg-core xserver-xorg-video-all xserver-xorg-input-all then dist-upgrade again.
Once it’s done without error you can reboot.
2. Removing KDE related software
To install your own compiled KDE suite, you should remove all kdelibs related software, particularly if you want to replace your actual KDE version with a new one. If you only want a test version (for development for example) this step is optional but you will need to take further precautions when setting your environment variable in the next step.
Removing all KDE related software is simple. As all KDE software depends on kdelibs, removing kdelibs will remove as well nearly all the KDE software. You will also need to remove specific KDE third party libraries (gathered in what I will call kdesupport) that are Strigi, Akonadi, Nepomuk, Taglib, Attica, Oxygen-icons, PolkitQt, QCA, QImageBlitz and utilities like Automoc and CppToXML.
Phonon is a special case. First it’s used by other non-KDE software (like VLC) and two different version exists. One provided by KDE developers and one provided with Qt since its version 4.6.0 called libqt4-phonon as Phonon have been integrated in Qt. The version provided in Sid simply called libphonon is equivalent to the KDE developers version and is quite more up-to-date. If you install this version you will don’t need to compile your own copy of VLC or some other music software or plug-ins. The version actually provided with Qt is not recommended as its a lighter version that may lead you to some compilation failures.
To remove KDE and kdesupport proceed with this command line as root (it’s supposed that you have the version in Sid installed) :
apt-get remove kdelibs5 libsoprano4 libakonadiprivate1 libtag1c2a \
libtag1-vanilla libstreamanalyzer0 libsearchclient0 libstrigiqtdbusclient0 \
libstreams0 automoc libqca1c2 libqca2 libattica0 kde-icons-oxygen \
libqimageblitz4 libpolkit-qt0 libpolkit-qt-1-0
To remove Phonon:
apt-get remove libqt4-phonon libphonon4
Please note that doing this will remove GoogleGadgets, VLC, Qt4 development files (so you will need to compile Qt as well) among some less known software and libraries. If you want them back you will need to compile that manually as well, which mean in most of the case remove all the Qt-libs and related software and building Qt and all the software that may depends on (which can be huge for some peoples).
To install the Phonon version I recommend take a look at the « Installing/building Qt » page. Do not uninstall Phonon now if you choose this solution.
Now you’re just clean to continue with the environment and build tools.
3. Installing minimum requirement
I will provide requirements on a per package basis. So, don’t be surprise if the dependencies provided here are very few. You will need to install here the compiler and its dependencies, GNU make and autotools, Subversion and GIT for source download and update and CMake (the configure tool and makefile generator used by KDE software). To install all of this use that command as root:
apt-get install build-essential cmake cmake-curses-gui subversion \
git-core automake autoconf libtool subversion-tools
4. Environment and build system
Now, your system is up-to-date enough so we can define some variables that will tunes how your KDE will be build and how it will be installed. This is a very crucial step and this is where you will have to do many choices. This is divided in two different main cases.
4.1. Building for day to day use
When you build a software for a day to day use, you need it to be well integrated in the system, to be optimized and efficient. That’s why I have choose the DFSG as a base to work. The best way to have the needed variables correctly defined at start-up and for every users is to edit the file /etc/profile with the add of the following lines:
# Create KDE temporary directory
if [ ! -d /tmp/${USER}-kde4 ]; then
mkdir /tmp/${USER}-kde4
fi
# Following DFSG KDE prefix would be /usr/
export KDEDIR=/usr/
export KDEDIRS=$KDEDIR
export KDETMP=/tmp/$USER-kde4
# $STRIGI_HOME=$KDEDIR is very strongly recommended
export STRIGI_HOME=${KDEDIR}
export QT_PLUGINS_DIR=$KDEDIR/lib/kde4/plugins:$QTDIR/lib${QT_PLUGINS_DIR+:}$QT_PLUGINS_DIR
# The following line is commented when $KDEDIR is already in the path
export PATH="${KDEDIR}/bin:${PATH}"
export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}${PKG_CONFIG_PATH+:}${KDEDIR}/lib/pkgconfig"
# Take a look further for CFLAGS tuning in "CFLAG and CXXFLAGS" chapter.
export CFLAGS="-O2 -m64 -pipe"
export CXXFLAGS=${CFLAGS}
# Create fmake alias for "Fast Make". Look "Tuning « fmake »" chapter.
alias fmake="make -j3"
Generally /usr/bin and /usr/local/bin are already in search path so you can comment or remove the export PATH=..... line (just like it should here) without problem if you use any of these path as KDEDIR. Never define KDEDIR to « / » (root) as this may be dangerous. If you don’t like DFSG path you can set KDEDIR to any possible value (traditionnally /opt/kde or just /opt). The other paths will be set accordingly. Be careful, once this is set and you’ve start the install of whatever it can be, it will be hard to go back and change properly. It can be easier to use non DFSG directories when updating to a new mlajor version of KDE 4 or Qt. For exemple if you decide to compile Qt yourself (and so all Qt applications) installing all that depends on Qt in /opt is a good idea. For exemple, when upgrading to a new Qt version a simple way to avoid version misunderstanding or mixing by the system, or duplicate file, etc. is to simply do a “rm -rfv /opt”…
Before rebooting or applying those changes read carefully 4.3 and 4.4 sections to tune things correctly for your system. To apply the changes without rebooting use the command source /etc/profile.
4.2. Building for test
When you build a test version, your needs are somewhat different. Installed files should be in a path separated from the rest of the system. That way you can easily remove the files to start a new clean install whenever it’s needed. For example library versions may change and if you do not erase them you may have multiple version of the same library. As well header files could not be stable and file names may change. Then, you probably want a stable version installed that makes the test installation a second one, so this is not good to define variables for the whole system. Here, you have two choices. Either you create a special user for the test, either you create a script to switch to the KDE test version (which lead to the same result). If you want to create a special user type the following as root:
useradd -m <user_name> -s /bin/bash
passwd <user_name>
Replace <user_name> with the user name you want. After taping passwd <user_name> it is asked you for the password of that user.
If you created a new user add those lines to your /home/<user_name>/.bashrc. If not add it to a script named ~/prep_test_build.sh with nano ~/prep_test_build.sh (you can choose another name and path, so just remember it):
# Create KDE temporary directory
if [ ! -d /tmp/${USER}-kde4-test ]; then
mkdir /tmp/${USER}-kde4-test
fi
# /opt/ is the usual path for such installation
export KDEDIR=/opt/kde-test/
export KDEDIRS=$KDEDIR
export KDETMP=/tmp/$USER-kde4
# $STRIGI_HOME=$KDEDIR is very strongly recommended
export STRIGI_HOME=${KDEDIR}
export QT_PLUGINS_DIR=$KDEDIR/lib/kde4/plugins:$QTDIR/lib${QT_PLUGINS_DIR+:}$QT_PLUGINS_DIR
# The following line is commented when $KDEDIR is already in the path
export PATH="${KDEDIR}/bin:${PATH}"
export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}${PKG_CONFIG_PATH+:}${KDEDIR}/lib/pkgconfig"
# Take a look further for CFLAGS tuning in "CFLAG and CXXFLAGS" chapter.
export CFLAGS="-O1 -m64 -pipe"
export CXXFLAGS=${CFLAGS}
# Create fmake alias for "Fast Make". Look "Tuning « fmake »" chapter.
alias fmake="make -j3"
Of course, you can choose something else for KDEDIR variable but do not use any DFSG path (/usr or /usr/local) unless you want to use KDE trunk for production use (not recommended) or if you have a computer specially configured for testing. If you put this into a script it is not needed to make it executable as it will have to be executed using the « source » command.
4.3. CFLAG and CXXFLAG
CFLAG and CXXFLAGS are variables that are used by the compiler to tune the compilation process. It is generally used to optimize compilation in order to use what you really have in your computer. If it is set correctly, performance must be somewhat greater than binaries provided by standard distributions. Even if we set global flags for your system you can always redefine it on a per package base even if it’s not really useful (unless you are developer). CFLAG is for C files and CXXFLAG for C++. Generally it is not needed to define them as different unless you want a very precise tuning (CXXFLAG may have more parameters), but this is not the purpose of this tutorial. For more information on CFLAG and CXXFLAG use your favorite web search engine. Here we will have identical CFLAG and CXXFLAG (this is the line CXXFLAG=$CFLAG).
An important parameters is -OX (in my script it’s set to -O2). This define the optimization level of the generated binaries. It accept values from 0 to 3 and S. -O0 means no optimization at all and -O3 the maximum optimization level. -OS means to optimize size of the executable instead of speed. The more the code is optimized, the more the execution speed will be fast, the more the memory needed for compilation will be important and slower the compilation will be. Please do not use -O3 unless you are sure of what you do cause generated executable may be very unstable. The best choice for a day to day use is -O2 and for test -O1 is enough cause quite faster to compile.
The -pipe parameter tells the compiler to use pipes (understand memory if you don’t know what is it) instead of temporary files while compilation. This is resulting in a much more fast compilation process but much more necessary memory. It is a good idea to use it unless you have less than 1 GB of RAM.
The -m64 parameter is for 64 bits users and allow the use of specific 64 bit instructions. If you have a 64 processor it is a good thing as the generated executable can be a bit faster.
Then you have the -march=<your_cpu>. I do not add it cause it’s not good in a generic tutorial but if you know precisely what your processor is it is a very good benefit to precise this. For example, if my processor is an Intel Dual Core T20XX the best CFLAG is -march=prescott. If you choose a value that is to high for your processor the compilation will fail so don’t worry if you want to test. You can find a complete list of processor with the corresponding march parameter on Gentoo wiki.
When yours flags are tuned you can test if compilation goes fine by executing this little script:
echo 'main(){}' > dummy.c && gcc -o dummy dummy.c
if [ -x dummy ]; then echo "Compilation OK";
else echo "Compilation failed"; fi
rm -f dummy.c dummy
If you have « Compilation OK » then everything will be good, elsewhere, change your CFLAG, until this is Ok. If you don’t want to manage this you can delete the CFLAG and CXXFLAG definitions. In that case the compiler will use basic parameters, that are Ok for everybody.
4.4. Tuning « fmake »
Modern computers are using multi-core processors. That means that for the operating system you have two or more processors running in parallel. To take advantage of this, we define an alias to the « make » command called « fmake » for « fast make ». You have to set it correctly for your system. Consider the following alias:
alias fmake="make -j3 -l90"
That means that 3 compilation jobs will be ran simultaneously (-j3) unless the average load of your processors are upper than 90% (-l90). Unless you need to do something else with the computer while compilation we do not use the -l parameter. Generally the best performance are gained when setting the number of simultaneous jobs to the number of processor available plus one. If I have a dual core (two processors) my -j parameter will be -j3. For a quad core the best is -j5 and so on.
Advanced users can define an alternative compiler with CC=<compiler_name> parameter. This very usefull when you want to use a compiler farm (see next page). For exemple, to use IceCream compiler farm your line will be something like:
alias fmake="make CC=icecc -j8"
4.5. Why not using MAKEFLAGS variable?
In fact, you can use it if you want… There’s many cases. First we have to define a priority. If a parameter is given in the make command line, it will override the one given in MAKEFLAGS. That means fmake parameter have the priority. We can use this to allow several make configuration in a very simple way. For example if you have a compiler farm you can disable its use by using make instead of fmake. Personally I prefer using the alias solution because some packages provides poor quality makefiles where source files dependencies are not set properly. In that case, the compilation may fail when using fmake. Therefore, if fmake fail I try with make. If it’s still fail the only thing to do is to Google-ize the problem!
