Hi, On Tue, Feb 13 2001 at 16:53 -0600, Avi Schwartz wrote:

Almost every KDE2 program I am trying to build fails during compilation for one reason or another (usually mismatch between method calls and what the compiler finds in the header files). I would like to hear from other people if they had more luck then I did and if they are using the SuSE RPMS or installed KDE2 from sources. If I would like to install from source, do I have to remove KDE1 and KDE2 from my system first? Any tips would be appreciated.

Compiling KDE is rather painless. Just get the whole source distribution and make sure you compile and install kdesupport, kdelibs and kdebase first (in that order). You don't have to remove older KDEs from your system, just install the new one to its own directory, e.g. /opt/kde-2.1-beta2. I did it like this: - untar the sources to /tmp - export KDEDIR=/opt/kde-2.1-beta2 - export PATH=$KDEDIR:$PATH - cd /tmp/kdesupport* - ./configure --prefix=$KDEDIR && make && make install - ldconfig; rehash - cd /tmp/kdelibs* - ./configure --prefix=$KDEDIR && make && make install - ldconfig; rehash - ... Ciao, Stefan -- Stefan Troeger o _ _ _ stefan@troeger.st __o __o /\_ _ \\o (_)\__/o (_) _`\<, _`\<, _>(_) (_)/<_ \_| \ _|/' \/ (_)/(_) (_)/(_) (_) (_) (_) (_)' _\o_

Hi Avi, My experience is that there are two kinds of KDE programs.... Those that require KDE1 and Qt-1.x and those that can compile with only KDE2 and Qt-2.x present. Those that can compile under KDE2.x and Qt-2.x only are ones that were made with development tools that are not dependent on Qt-1.x or KDE1 libraries. The rest are. Unfortunately, KDevelp is one of those retarded applications that STILL requires libqt.so.1 (which links to libqt.so.1.44) and some other older libraries. I just downloaded and attempted to install KDevelop-1.3-1 using SuSE 7.0 binaries, on the KDevelop site, that were made yesterday, 2/11/2001. While I appreciate the work Mathias is doing, it seems like a waste of effort. KDE2 is already at Qt-2.2 or above and KDevelop still requires KDE1 and Qt-1.x libraries!!! Unbelievable! Creating an RPM package is hard work, but making it for a subset of SuSE users that keep both KDE1 & KDE2 and Qt-1.x and Qt-2.x on their system is really narrowing your target users to a small number. To install KDevelop-1.3-1 you have to enter four rpms in the following order: C_reference kdelibdocs kdev_htdig kdevelop The first three installed with no problems. The last gave the following dependency errors: JLKreps:/opt # rpm -i kdevelop-1.3-1.i586.rpm error: failed dependencies: libjscript.so.2 is needed by kdevelop-1.3-1 libkdecore.so.2 is needed by kdevelop-1.3-1 libkdeui.so.2 is needed by kdevelop-1.3-1 libkfile.so.2 is needed by kdevelop-1.3-1 libkfm.so.2 is needed by kdevelop-1.3-1 libkhtmlw.so.2 is needed by kdevelop-1.3-1 libkimgio.so.2 is needed by kdevelop-1.3-1 libqt.so.1 is needed by kdevelop-1.3-1 JLKreps:/opt # So, I am still without KDevelop unless I want to remove Qt-2.x and KDE2 and go back and reinstall KDE1 and Qt-1.x and then add KDE2 and Qt-2.x, thus being REDUNDANT. This is STUPID! What were they smoking when they decided to go this route? While I was running KDE1 and Qt-1.x I found KDevelop to be a fantasic GUI RAD tool. Until they bring it back into the 21st century it will not waste space on my box. Just at a time when they should be putting their act togeather and building KDevelop FOR KDE2 on the what they've learned from their KDE1 version, they ball and chain themselves to KDE1 and Qt-1.x libraries! Now, I don't plan to retry KDevelop until it will load on a system that has ONLY Qt-2.x and KDE2.x. Meanwhile, the $99 version of Kylix will probably be out by June, probably long before KDevelop rejoins the 21st century. JLK On Tuesday 13 February 2001 16:53, Avi Schwartz wrote:

Hi,

Almost every KDE2 program I am trying to build fails during compilation for one reason or another (usually mismatch between method calls and what the compiler finds in the header files). I would like to hear from other people if they had more luck then I did and if they are using the SuSE RPMS or installed KDE2 from sources. If I would like to install from source, do I have to remove KDE1 and KDE2 from my system first? Any tips would be appreciated.

Avi

-- Athiests believe they know there is no god. Agnostics know they believe there is no god. Thiests believe there is a god. Christians believe in God through His Son, Jesus Christ.

On Tuesday 13 February 2001 17:53, Avi Schwartz wrote:

Hi,

Almost every KDE2 program I am trying to build fails during compilation for one reason or another (usually mismatch between method calls and what the compiler finds in the header files). I would like to hear from other people if they had more luck then I did and if they are using the SuSE RPMS or installed KDE2 from sources. If I would like to install from source, do I have to remove KDE1 and KDE2 from my system first? Any tips would be appreciated.

Avi

Avi, It really depends what you seek. If you want to do it just to get the very latest KDE, it may not be worth it. As Ben suggested the 2.1Beta is pretty nice. It takes me the better part ot a siderial day to compile the entire CVS tree. The last two I did, broke. I believe that was due to my not having compiled the QT with all the switches thrown. You should be able to get by with the QT from SuSE's RPM. If you have a box with at least a 300Mhz chip and 64 Meg of RAM you may be able to get the entire tree to build before the sun rises twice. Of course you _don't_ need to build _all_ the stuff from the "snapshots" directory. There is a good script in that directory called something like "compile_script.sh." As Stefan has suggested you can build into a different directory. Indeed you can have each KDE on your box use a different QT. Herein is another good reason to snag the betas from SuSE (out on the KDE site). They have provided a wonderful /opt/kde2/bin/startkde script which you can hack to your liking. In order to get the new build to be seen by the KDM you are running, crack open the /opt/kde*/share/config/kdmrc and add a unique string to the SessionTypes variable identifying your new version. Then (assuming you put your build in /opt/kde21, and called it KDE21 in the /opt/kde*/share/config/kdmrc) do: ln -s /opt/kde21/bin/startkde /usr/X11R6/bin/KDE21 The KDM you are using is determined by the /usr/sbin/rcxdm. The default is /opt/kde/bin/kdm. I use the startkde from SuSE - which I copy to my build - to set the environment for my KDE21 session. I believe they do some magic to make both QT versions available in that environment. Now, in the great Norse tradition, since you have the prose version here's the poetic version: - Get the source form: ftp://ftp.kde.org/pub/kde/unstable/CVS/snapshots/current - Edit the compile_script and hack it to match your system ( This determines, among other things, where the make install puts the finished build as well as what actual tarballs get built.) (NB: non-beta and some of the other non-core stuff probably will _not_ compile correctly. - Run the script (it does all the uncompressing, untarring, configurring, making and installing for you) - Wait 10 to 24 hours for it to build - Edit the rcxdm to determine which kdm you will be using - Edit the corresponding /opt/kde*/share/config/kdmrc and add a unique ID for your build to the SessionTypes variable - Copy SuSE's startkde script from their beta to the corresponding location in your build and hack accordingly. (i.e. change the pointers from /opt/kde2 to /opt/kde2.1) - Symlink the startkde to /usr/X11R6/bin using the unique ID from the kdmrc as the file name of the symlink.( ln -s /opt/kde21/bin/startkde /usr/X11R6/bin/KDE21 ) - Run rcxdm restart from a tty console - Log in to the new kde by selecting it from the pick list in the kdm. - Let me know if I omitted anything major. HTH Steve