On Monday 24 September 2001 07:14 am,[EMAIL PROTECTED] wrote:
> I'd like to upgrade my kde from 2.1.2 to 2.2.1 on my eD2.4. Since
> there aren't any rpms, compiling is the way to go. What precautions
> should I take to reduce the chance of the compilation messing my
> system up? Should I first remove kde 2.1.1 completely or can I have
> both on my system at the same time like kde 1.1.2 and kde 2.1.2? TIA
>
> Mark
Here are suggestions from the KDE gods. I tried to update some time
ago without following these words from the gods and made a mess.
Success was had when I followed these steps. I wish I had seen these
before I started ;- )
On Sunday 23 September 2001 08:52 am, akar wrote:
> It seems that with every upgrade of KDE a lot of the same questions
> get asked time after time and this is compounded by the fact that
> very little in the way of specific docs is available especially with
> regard to version specific issues. So lets see if we can rectify
> that...
>
> HINTS & TIPS FOR COMPILING KDE 2.2.x
>
> 1.....Can I compile over the top of my old kde
> 2.....Speeding up KDE; Objprelink and optimisations
> 3.....What extra libs/packages do I need
>
>
> 1) CAN I COMPILE OVER THE TOP OF MY OLD VERSION.
>
> The short answer is that a totally clean environment is preferable.
> If your old version was installed by compiling; or if rpm and all kde
> and kde-devel rpms were installed, then this can be quite unsafe.
> Even if you are compiling into a new location; if the old location is
> in the general system path (like /usr for Redhat and Mandrake or
> /usr/local) then it is unsafe.
>
> The problem is that when you are building KDE it should only look at
> the header files that come with it. But since it is linking with
> other stuff on your system, its search path for headers includes all
> those common system location in which your OLD header may lie. The
> configure script SHOULD always find things in its own tree first but
> in practice for some reason this does not always happen.
>
> The Solution? If a system like RedHat / Md where kde is installed in
> /usr just remove all kde related devel rpms of your old version
> first. For other systems where your old version was compiled or is
> built into a non standard path (like /opt/kde2 or /usr/local/kde) it
> is always a good idea to keep your original install location because
> then you dont have to modify any system scripts. Simply rename your
> old KDEDIR location (KDEDIR = the root of the install location) to
> something else; then you can use the old location or preferably make
> the old location a symlnk. eg:
>
> /opt/kde2 was original install of kde2.1
> /opt/kdeold .. you have renamed it to kdeold
> /opt/kdenew221 ... You create a directory where kde2.2.x will go
> /opt/kde2 --> /opt/kdenew221 ....You sysmlnk the original location to
> where KDE will now be installed. You refer to it simply as /opt/kde2
> and it is already set as KDEDIR so you dont have to touch any
> scripts.
>
> People compiling for Redhat/Mandrake should consider compiling to
> such a location rather than the default of /usr but you will need to
> add a small script in /etc/profile.d called kde,sh containing;
>
> KDEDIR="/opt/kde2"
> QTDIR="/usr/lib/qt2"
> PATH="$KDEDIR/bin:$PATH:$QTDIR/bin"
> LD_LIBRARY_PATH="$KDEDIR/lib:$QTDIR/lib:$LD_LIBRARY_PATH"
> export KDEDIR QTDIR PATH LD_LIBRARY_PATH
>
> 2) SPEEDING UP KDE; OBJPRELINK and OPTIMISING.
>
> i/ You may not have noticed but objprelink has been built in as a
> configure option in kde2.2x which saves a lot of nasty patching.
> Objprelink is a technique whereby expensive (timewise) absolute
> relocations in a program are replaced with relatively cheap relative
> relocations using a stub. It does work and gives a 30-50% increase in
> load time with konq for example. It is essential if you use this that
> you rebuild your qt libraries as well as any kde app is making big
> usage of them. Just setting the --enable --objprelink option will
> do nothing; You must build the tiny objprelink binary and
> instructions at;
> http://www.research.att.com/~leonb/objprelink/
>
> ii/ Optimising your compile
>
> If you are going to the trouble of compiling KDE you should build a
> version optimised for your CPU. This is not hard, it is just a matter
> of exporting some flags before the configure and make (just before
> the make really but if you didnt write the scrips, do both just in
> case) Usually you would put the lines in a little script but just
> typing them in is fine.
>
> export CXXFLAGS="-O3 -march=i686"
> export CPPFLAGS="-O3 -march=i686"
> export CFLAGS="-O3 -march=i686"
>
> where the -O3 is capital-O not zero and i686 is your cpu. It could be
> athlon (only if using gcc >2.96) So the standard gcc2.95 will only
> allow upto i686 which is suitable for any greater than/equal to
> Pentium II chip. If you have a normal pentium you can use i586. I
> have doubts about pure athlon compiling with 2.96 anyhow as does seem
> to introduce a lot of padding when it and objprelink are used
> together. By itself the athlon compile was very fast though and was
> faster still with objprelink despite the padding and strange
> relocation conversions.
> It is not necessary to use the -mcpu switch as -march
> automatically implies -mcpu and -mcpu does nothing on its own unless
> march is also set.
>
> Remember to use the -disable-debug and enable-final switches in
> configure (-final is for the -03 optimisations AFAIK)
>
>
>
> 3) WHAT EXTRA PACKAGES DO I NEED?
>
> i/ Apart from the base kde packages you need;
> cdparanoia-III-alpha9.8 (or beta ) minimum and
> lame 3.89(beta) ....if you want to be able to rip mp3 and ogg file
> from CD. Note that the cdparanoia and devel rpms on you CD probably
> are not suitable as you need to build shared libs and the rpms either
> dont have them or they dont match the included header files. It is
> the libraries from lame you are after rather than just the lame app
> and you MUST get the
> unofficial/unreleased 3.89 (or later) beta as earlier official
> releases do not contain code that you may need to allow you to rip
> mp3s (purely as a hypothetical educational proposition: to actually
> do so may infringe on patent rights)
> KDE does not endorse or recommend the building of this module, it is
> a purely speculative example that leaked from a parallel universe.
>
>
> ii/ pcre-3.4 (or later) for libpcre If you want extended regular
> expression support in javascript and possibly other apps you should
> install this. It compiles in about 30 seconds
>
> iii/ cups; I recommend trying this print system. The new kde has
> extensive support for it as well as all print sub-systems now. If you
> already have cups on your system make sure you install the cups-devel
> rpm as well
>
> iv/ openssl; KDE no longer supports openssl 0.9.5 like in release
> previous to kde2.2 So make sure you have openssl 0.9.6 (either a or b
> version) and its devel rpm. Be careful as a lot of current distros
> have both 0.9.5 and 0.9.6 and their devel paks on the CDs, so dont
> mix n match.
>
> v/ libxml2; You need this if you want the kde help centre to work.
> Even so it will not have search functionality. You need at least
> version 2.3.4 but I wonder about that. Use at least 2.4.0. If
> configure complains it cant find it, then it is either in an
> unexpected location (use symlnks or recompile it into /usr) or there
> is a conflict with libxml0 (version 1.8) headers and you should
> remove that devel rpm and then delete the config.cache and configure
> again.
>
>
> MISC: For a standalone home computer only connected to the internet
> by phone and only in its own small network if at all, a lot of
> options can br turned off as being unnecessary. I turn off libfam,
> pam, any other authorisation stuff, I have alsa as well but turn it
> off. Do a configure --help in each package to see the options.
>
> If you had a configure/make error and had to add a library or make
> changes etc then before running configure again do a make clean and
> then delete the config.cache and status file.
--
Tony Alfrey
[EMAIL PROTECTED]
"I'd rather be sailing"
_______________________________________________
http://linux.nf -- [EMAIL PROTECTED]
Archives, Subscribe, Unsubscribe, Digest, Etc
->http://linux.nf/mailman/listinfo/linux-users
