Projects/KDE on Solaris

Solaris (and OpenSolaris) are Free Software operating systems released under the CDDL by Sun Microsystems. They are vaguely BSD-like. KDE4 runs on this operating system.

The KDE Project on the OpenSolaris site is intended to be the definitive source of information, but this page on TechBase is intended to collect information, porting and compilation guides, etc. Since TechBase is a wiki, this is much easier than going through the OpenSolaris editing process.

Compilation and Installation

Getting KDE4 on your Solaris machine is a three step process: you need KBE, the KDE Build Environment, as it contains a bunch of tools you need to build KDE4 with. Then there are the dependencies, for which we have RPM-style spec files. And then there is KDE4 itself.

KBE Compilation and Installation

KBE is the "KDE Build Environment" which gives you the tools needed to build the dependencies of KDE and then KDE itself. You can get a tarball of KBE and unpack that. SVN is included in there, which we need later. There is also make and cmake and other bits and pieces; vim is also included to soothe the nerves of vi-using KDE people like me.

wget http://www.bionicmutton.org/solaris/KBE.tar.gz

/usr/sfw/bin/gtar xvzf KBE.tar.gz
cd KBE

bash kbe-install

These four commands will fetch and unpack and then start the KBE install script. This script will install dependencies that KBE has which are on the Solaris install media (SUNWi2c and twenty others, I think). Then it will start building the packages for KBE itself, starting with pkgtool. It should go off without a hitch (otherwise post output to the mailing list). If it craps out somehow, you will have to start over from scratch: pkgrm -Y KBE ; bash kbe-install.

Once KBE is done installing, you can check with pkginfo -c KBE to see what it has installed. You will have a /opt/kdebld filled with "stuff". Right. Now source the environment from KBE, which you will use in later steps:

. /opt/kdebld/bin/env.sh

(Use env.csh if that's your poison). If you don't have an env.sh at the end, something is definitely wrong. I end up with 210 or so files in /opt/kdebld/bin, so keep that in mind as a metric. There are 23 packages in the KBE group.

Avoiding KBE dependencies

You can give kbe-install a --nodeps to avoid the SUNW packages that it wants to install. You do need to have Sun Studio 12 9/07 or later installed; any later patches are welcome as well. I do not know what avoiding the SUNW dependencies will do, actually: they don't really seem to be essential, but I would suggest skipping this step only if you don't have the install media handy.

Using packages

There are SYSV packages for the parts of KBE available from bionicmutton.org, see the index of packages for details. You can get the packages from the individual links there or fetch all of them with wget as follows. For x86 / amd64 machines, use "x86" for <arch>, for SPARC machines use "SPARC".

wget --recursive http://www.bionicmutton.org/solaris/KBE/<arch>/

Use pkgadd on each unpacked package to install it.

Getting help

If kbe-install does not work, please pop into #kde-solaris on Freenode (irc.kde.org works) and ask questions.

Dependencies

KDE4 has a lot of dependencies. Without getting near to porting all of the optional dependencies for the first four KDE SVN modules, the KDE Solaris team has already done about 50 different Open Source packages. These need to be installed first before you can compile KDE4. The packages range from single header files to Qt 4.3.1, which is kind of big. All of the dependencies are distributed as SysV packages.

Getting spec files

The next part of the equation is getting all of the dependencies of KDE to build. These are numerous, multifarious, and huge. And at least one of them will break. It is a 3GB SVN checkout, at least (and will use about 6GB of disk space). $ . /opt/kdebld/bin/env.sh $ nohup svn co https://svn2.cvsdude.com/kdesolaris/trunk Dude & $ tail -f nohup.out Find something to do while the SVN download runs. It takes a while. Probably you'll have to $ pgrep -l svn; kill xxxx and start the checkout again once or twice. When it's done, go to the SPECS. $ cd Dude/SPECS

In the SPECS/ directory you will find a whole bunch of *.pspc files. These represent all the dependencies currently packaged. Some of these may conflict with files and packages already sitting in your ~/packages/ directory, so it is safest to remove ~/packages/BUILD/* and ~/packages/SPECS/* and ~/packages/SOURCES/* (but not the directories themselves).

The pspc files are "Pre-SPEC files", meaning that they need to be processed in order to produce the .spec files that pkgtool understands. We do this for two reasons:

• The build and install sequence for each package is the same; all the logic lives in the Solaris/ directory of each source tarball.
• We need to create 32- and 64-bit spec files which are almost alike anyway.

Patching your System

Boost, one of the dependencies, builds Python bindings, and the Python headers installed by the system Python package are broken. So you will have to edit them as root to fix this. Fortunately it will take a while before Boost gets there, so start the make process and then an editor. In /usr/include/python2.4/pyport.h there is a gethostname() prototype that must be commented out. Or get a good copy of pyport.h here.

Compilation

You will have to source the environment from KBE and then run make in the Dude/SPECS folder: $ cd Dude/SPECS; nohup time make & tail -f nohup.out That will start building all of the packages, one by one. For each package, the perl script Respect.pl is used to create the .spec files and tar up the source directory which you have checked out of SVN. Then pkgtool is used to build the resulting packages (both 32- and 64-bit if your hardware supports it). Typical output from one package looks like this:

perl Respect.pl --with-all --without-upload --without-build flac Respect: Reading pspc file flac ... Respect: Reading pspc file flac ... Respect: Creating spec file flac.spec ... Respect: Checking consistency ... Respect: Creating spec file flac.spec ... Respect: Warning - no dependency packages specified. Respect: Installing replacement libtool ... Respect: Creating source tarball ... Respect: Copying tarball to packages/SOURCES ... Respect: Skipping upload of tarball. Respect: Use --with-upload to enable. Respect: Skipping package build. Respect: Use --with-build to enable. pkginfo -q "FOSSflac" || pkgtool build "FOSSflac.spec" INFO: Copying %use'd or %include'd spec files to SPECS directory INFO: Processing spec files INFO: Finding sources INFO: Running pkgbuild -ba [...] FOSSflac.spec (FOSSflac)

If a package build fails, there will be a /tmp/FOSS*.log file explaining what went wrong. If configure fails in these packages, look for /tmp/config.log as well. Unfortunately pkgtool seems to destroy the build results directory even when it fails; you may also be able to look into ~/packages/BUILD/ to find the directory where things were building.

Compiling by hand

You may want to work on a single pspc file or a single package by hand. Respect.pl has a whole bunch of options, but what you will most commonly do is create .spec files, create a tarball, build and install the package. This is straightforward:perl Respect.pl --with-all --without-upload pspc-file If you forget the --without-upload, it will try uploading the resulting package to bionicmutton, which probably is not what you want.

Using packages

You can get packages from bionicmutton.org just as you can for KBE. Use

wget --recursive http://www.bionicmutton.org/solaris/FOSS/<arch>

Getting help

As usual, the IRC channel is a good place to start, but you must be able to pastebin compilation errors in order to get any help.

KDE4 Proper

KDE4 still builds out of KDE SVN. We have a setup that applies a handful of Solaris-specific patches to the code and then builds everything. We don't use kdesvn-build yet, but probably should when there are no external patches left.

Setting up an SVN checkout

Get a checkout of KDE SVN trunk, like so:

/opt/kdebld/bin/svn co svn://anonsvn.kde.org/home/kde/trunk/KDE

That's a huge checkout. Remember where you put it.

Using the build system

The build system lives in CVSDude SVN, so you need to check it out as well:

/opt/kdebld/bin/svn co https://svn2.cvsdude.com/kdesolaris/trunk/Build

Now is probably the right time to source /opt/kdebld/bin/env.sh again. Notice that Build/ just contains Makefiles. Everything here is driven by (GNU) make.

Configuration is stored in Makefile.config and you can override most of that in a file Makefile.config.local. The contents of my local configuration file are as follows:KDESVN_DIR=/export/home/adridg/KDE DESTRUCTIVE_UNPACK=YESThat ought to be self-explanitory: I have the KDE SVN checkout under ~/KDE.

A good trial run is of the kdesupport SVN module, so run make -f Makefile.kdesupport

Getting help

The IRC channel is never too busy.

To-Do

KDE4 on Solaris is not done yet. Not by a long shot. Most of the time it compiles, but there is much cleaning up of the codebase and dependencies to do. We list them here:

• krb5-config --libs includes all the cflags, not just the libraries. This breaks kio_http. Part of MIT-KERBEROS dependency.
• iconv_open fails in all Qt applications; it looks like it is trying a non-existent encoding -- but why?

KNOWN ISSUES

• glew - X11/openwin GL libs insanity
• unixodbc - build error
• canna, nas - Imakefile based build system is nightmare. Nas build fine, but without cflags and so on ... all binaries are 32bit
• x264 - build, link error
• dirmngr - build issue (libiconv x iconv)
• libgsm - setup wrong rpath for libgsm.so
• gnutls - build issue in gnutls-extra lib

Those tools aren't possible to build at this time. I'm still working on. keep tuned.

luc^