KDE4

Ken Moffat ken at linuxfromscratch.org
Sun Jan 13 11:59:40 PST 2008


On Sun, Jan 13, 2008 at 11:19:28AM -0600, Bruce Dubbs wrote:
> I've started to look at KDE4 and wondered if anyone else has started to
> build it.
> 
> According to http://techbase.kde.org/Getting_Started/Build/KDE4 it looks
> like there will be several new packages needed:
> 
> qt4
> libclucene
> librdf
> boost
 /me groans, a little.
> cmake
 Tried that quite a long while ago, ISTR KDE4 was still 'work in
progress' at that time and I didn't get anywhere with it.  Cmake
didn't seem difficult (on x86).
> 
> as well as some others that I'm not sure about.
> 
> arts is no longer a part of kde, but I'm not sure yet if it is needed at
> all.
> 
> It looks like HAL and dBus will be required.
 /me groans a lot (at hal).

 Boost is "interesting" - it uses its own build system (bjam), but
fortunately there is a version shipped with it:
 cd tools/bin/src && ./build.sh gcc && cd ../../../

 For gcc-4.2.2, and perhaps for 4.1, that needs a patch - I got the
link from cblfs:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=22;filename=boost.diff;att=1;bug=367825

 I'm not sure how much of the patch is actually needed.  I'm fairly
sure the changes to make1.c are mandatory, and probably native.c,
newstr.c, but the addition of -fno-strict-aliasing to the jam files
might not be necessary.

Then set up a few variables (I put *everything* in /usr)

BOOSTPYTHON=$(python -c 'import sys; print sys.version[:3]')

GCCVERSION=`gcc --version | head -n 1 | sed 's/[^0-9.]//g'`

BJAM=tools/jam/src/bin.linuxx86/bjam
[ a different directory on other architectures ]
echo "using gcc : ${GCCVERSION} : g++   ;" \
  >>tools/build/v2/user-config.jam
$BJAM -sBOOST_ROOT=$PWD -sPYTHON_ROOT=/usr \
  -sPYTHON_VERSION=$BOOSTPYTHON -sBUILD="release" \
  --prefix=/usr --layout=system

 My notes say that --layout=system handles the unversioned headers,
and is documented in Jamfile.v2.  The aim is to put all the headers
into /usr/include/boost instead of /usr/include/boost-1_34_1/boost/.
I would settle for /usr/include/boost-1_34_1/ but that isn't on offer
 - maybe BLFS should go with the overlong path for people who
upgrade in place.

 The real pain is for those who have a small-ish '/' (or '/usr') and
don't want the static and debug versions of the libraries : my
experience is that it installs everything unless you can find the
correct magic imprecation for the current version of bjam - I failed
in that, and filled the disk before it was complete.  FWIW, at the end
of the build (before installing), on x86_64 (pure64) the boost tree
occupied 1.2GB.  I'm sure x86 will be a bit smaller.

 Fortunately, I found that the way fedora do the install can be
hacked about to restrict it to just headers and non-debug .so
libraries, but some of the version symlinks (.so.3 as well as
.so.1.34.1) are non-intuitive and will no doubt change with newer
versions.  But, BLFS doesn't go out of its way to restrict installed
libraries with --disable-static, so it's really only the space which
is the pain and suggestions for saving space can go in the wiki.

 As for hal, you guys seem to have it working, so I suppose it isn't
a problem.  I still can't figure out why anybody would *want* it,
maybe that just shows a lack of imagination, or excessive suspicion
about automation tools which try to guess what I want to do (e.g.
I've seen it when I was trying gnomebaker under debian: put in an
audio cd, get a dialog asking silly questions - the application I
wanted was already open).

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce



More information about the blfs-dev mailing list