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 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
