LinuxPlanet - Print - Leading and Bleeding with XFree86 4.0 and KDE 2 Beta

Leading and Bleeding with XFree86 4.0 and KDE 2 Beta

By: Scott Courtney
Monday, May 15, 2000 10:11:30 AM EST
URL: http://www.linuxplanet.com/linuxplanet/previews/1833/1/

An Installation Overview

It all started with an annoying bug in KMail, and it has ended with my primary Linux machine running a new version of glibc, the latest XFree86, and the brand-new beta of KDE. In this article, written just a few hours after all this came to be, I'll walk you through the installation process and give a brief first look at the new KDE. (You can take a quick peak at KDE 2 in the accompanying figure; other screen shots can be found later in the article.

Fair warning: This is an installation overview and a first impression of the new KDE, not a tutorial. If you know more than me you don't need my help, and if you know less than me you have no business trying this at home. If you're a newbie, just skip to the KDE "first look" section and enjoy knowing that this will soon be coming to a desktop near you (the KDE team is saying late summer). Or, if you really want to try this, ask a more experienced friend or users' group to help you out. If you're a veteran Linux guru, this article will give you a synopsis of the steps I followed (hopefully helping you to avoid some of the empirical parts). Veteran or newbie alike, if you decide to try anything described here--make a system backup of the old version first!

Now, shall we begin at the beginning? In other words, why am I doing this to a perfectly good Linux machine?

I had KDE 1.1.2 installed, running, and very stable on my Caldera OpenLinux 2.3 machine. KDE was working great, and I was happy with it. I looked at GNOME, liked it as well, but didn't have any real reason to switch.

The only thing I hated about KDE was that KMail wouldn't send messages. I had tinkered with the account-setup options, tried several different SMTP servers both on my local host and on my ISP's network, and compared the settings against other mailers on my machine. I could even send mail by telnetting to port 25 on the SMTP relay and typing the headers by hand. But when I clicked the "Send" button in KMail, nothing happened. No message sent, no message queued, and no error message in any log I could find. I pored over documentation and help files, posted to the Caldera users' e-mail list, and pestered my colleagues. No help in the docs, and no one had ever seen my problem before, nor could tell me what to do about it.

Worse yet, I had personally set up KDE on Linux systems I built for two or three friends, and not one of them had any problems at all! There are other e-mail programs, including excellent console-based apps, but I want to be able to run what my non-techie friends are running so that I can better support them. Even if KMail ends up not being my own choice for e-mail, I need it running on my workstation. I knew there had to be a way to make this work, and I was determined to find it!

In desperation, I decided to follow a really wild piece of advice from Dennis Powell, KDE wizard and writer of the excellent book, Practical KDE. Dennis, or "Dep" as he's called online, suggested that I try the alpha code of KDE2. I did a double-take at this, because e-mail is mission-critical to me and I couldn't imagine running my whole desktop on beta code, let alone on something that's called alpha.

Dep was kind enough to send me an early draft of a HOWTO-like document he's writing, which explains very lucidly how to install the snapshot builds of KDE2 and how to safely make it coexist with KDE 1.x. You can't run both at once, but you can switch back and forth as needed. I read his article carefully (by the way, it's not ready for publication yet, so I can't tell you where to get a copy--but there's a similar document linked from the Documentation section of the new www.kde.com Web site) and decided that this was something I could do. Mind you, I don't lightly approach trying a source build of extremely large and complex C/C++ projects. I'm a Java and shell-script guy. I know C, but not well enough to debug anything down in the bowels of KDE. But I have enough confidence in my Linux skills to be able to safely back out anything that failed, so I figured I'd give it a try.

Then I got carried away with things. I had previously installed (successfully) the new XFree86 4.0 on my Dell laptop, and it was working great. The source refused to build under Caldera 2.3, but the binaries went right in. It even correctly detected the weird flavor of ATI Rage Pro that lives in the Inspiron 7000. If it could do that, I figured, installing it on my desktop machine with an ATI Xpert98 would be a breeze. Besides, I reasoned that if I already had the machine down to console mode for the KDE build, I might as well plop XF86 4.0 on there too. Everybody said that KDE2 was faster than KDE1, and like any other good Penguin I have an infinite craving for faster systems.

Then the folks at KDE announced the first beta for May 11. That did it! I was hooked! I held my breath (see how blue I am?) until The Day arrived, then grabbed the code as fast as my cable modem could snarf the files. I was off to the races!

Well, I was at the starting gate, anyway.

Step 1: Upgrading glibc

Dep and another colleague had suggested I take a look at my glibc version before installing XF86 4.0 or KDE2, and they recommended 2.1.3. I was at 2.1.1, so the first thing I did was to upgrade. Given how central glibc is to the entire system, I was expecting this to be a nightmare. It actually turned out to be the easiest part of the whole process. I just grabbed the source tarball for glibc 2.1.3 itself, plus the appropriate versions of glibc crypt and linuxthreads. Crypt and linuxthreads get unpacked inside the source directory. Then I ran:

./configure --enable-add-ons=crypt,linuxthreads
make
make install

from that same directory. Everything worked fine. (Note that if your previous version of glibc came from an RPM, your RPM database is now out of sync. I made a conscious choice on my machine that I didn't care, but you may want to take a more deliberate installation path and use the rpm command to uninstall the old version after making a careful backup.) You may not even need to do this step; I upgraded because I trusted the people who recommended it, not for a specific technical reason.

Step 2: Installing XFree86 4.0

XFree86 4.0, available from http://www.xfree86.org/, is "released" but the development team's web site says that 3.3.6 is still the more stable version and recommended for most users. There are substantial performance improvements in 4.0 and a new format for the critical XF86Config file. I had seen such a substantial boost in speed on the Dell laptop that I was drooling to get XFree86 4.0 on my desktop as well (especially since I no longer have that laptop).

I have tried unsuccessfully to build XFree86 4.0 from source on three Caldera OpenLinux systems. The make step always hangs while building xterm, and I'm not enough of a C++ wizard to know why. Dep says that if you kill (from another console) the particular step that's hanging (not make itself), the process actually continues and apparently suffers no ill effects (it's already done building xterm at the point of failure, but it hasn't figured that out yet). I had reached my frustration limit by the time I got that tip, so I never got around to trying it. Instead, I simply installed from the binaries that I had already downloaded. Having Caldera OpenLinux 2.3 and glibc 2.1.3, the binaries I used were those for glibc 2.1. Specifically, I downloaded them from ftp://ftp.xfree86.org/pub/XFree86/4.0/binaries/Linux-ix86-glibc21/. The mirror sites weren't yet updated when I went looking for this version, but they may be by now, so you might want to check your nearest mirror first.

If you're running XFree86 3.x.x now, take the time to make a backup of /etc/X11, /usr/X11R6, and /etc/XF86Config. If you have to back 4.0 out for some reason, this step will save you a lot of grief. The XFree team recommends installing 4.0 over the top of 3.x.x, because some of your X11 applications that live under /usr/X11R6 may not be included in the new version. By the way, you will want to run the installation of both XFree86 and KDE 2.0 with the system at a console mode prompt, not inside KDE or any other graphical interface. This is important!

XFree86 4.0 comes with a handy installer called Xinstall.sh, and the developers strongly recommend the use of this utility. The only areas where I diverged from the instructions were that I didn't install over my previous version (and therefore had to manually copy some binaries back into the /usr/X11R6 directory from my backup area), and I installed under /opt/X11R6 with a symbolic link from /usr/X11R6. This last part was because I didn't have room on my /usr filesystem for two versions of XFree, which is quite large (over 80 meg as installed on my machine). Xinstall.sh itself worked exactly as advertised, and I had an installed XFree86 4.0 in just a few minutes.

Unfortunately, installed is not the same as working. The next step after running Xinstall.sh is to run XFree86 -configure to detect the video card. This failed immediately, complaining that it couldn't find drivers for the 3DFX Voodoo series of cards (the driver is called "Glide," by the way). It turns out that XFree tries to load the Voodoo server module from its modules directory, but that module depends on the Glide driver. Since I don't have a Voodoo card, I simply moved the offending module out of the directory so XFree86 wouldn't try to load it any more. The -configure step now worked, but all it did was install a generic VGA. My ATI card didn't auto-detect.

The backup plan was to fall back to the old standby, SuperProbe and xf86config. SuperProbe (that's the actual name of the binary, including the upper case) is a handy utility that can tell you more than you ever wanted to know about your video card. Between that and the manual for my Sony monitor, I gathered all the hardware data and ran xf86config to build the configuration file, /etc/X11/XF86Config. Running xf86config is a simple matter of having the right info at hand and answering the prompts that it displays as to what kind of mouse, keyboard, monitor, and video card you have. My Sony 210GS monitor can handle horizontal rates of 31.5 to 70 kilohertz and vertical refresh rates of 50 to 120 hertz. For the choice of video cards, I chose #52 on the list, the "ATI 264GT (3D Rage Pro)." This matched what SuperProbe had told me about the ATI Xpert98.

Alas, though xf86config ran perfectly and even had my card on the list, it ended by telling me that my adapter was unsupported and would only run as generic VGA. That being, er, less than optimum for a Web development workstation, I did some empirical hacking around at the XF86Config file, and eventually ended up with one that worked. The relevant sections of the file for the ATI Xpert98 look like this:

Section "Device"
    Identifier  "ATI Mach64 GT (264GT), aka 3D RAGE"
    Driver      "ati"
    VideoRam    8192
EndSection

 Identifier  "Screen 1"
    Device      "ATI Mach64 GT (264GT), aka 3D RAGE"
    Monitor     "Sony 210GS"
    DefaultDepth 24
    Subsection "Display"
        Depth       24
        Modes       "1280x1024"
        ViewPort    0 0
    EndSubsection
EndSection

Of course, your system's configuration will be different unless you have the same hardware as me.

By now it was 11:30 p.m., and I had a working X11 server. The only remaining step was to copy the old version of /etc/X11/xinit/kdeinitrc from the backup directory to the new /etc/X11/xinit directory, since that file is not part of the standard XFree86 distribution.

I was up and running, still in the old KDE but now with the new XFree86 4.0! The only problem I've found so far is that WordPerfect 8 is broken on my system, claiming that it can't load the libXt.so.6 library file.

Depending on your distribution, you may need to change the file that starts your KDE or other X11 desktop. On Caldera 2.3, the affected file is /etc/rc.d/rc.gui, and the only change I needed was to make the directory correct for the XF86Config file. Specifically:

XC=/etc/XF86Config

was changed to:

XC=/etc/X11/XF86Config

This is required so that init processing will be able to start X11.

Step 3: Installing KDE 2 Beta

Having fought all the alligators, I at last was able to refocus on my original goal of draining the swamp. Specifically, this was all aimed at getting KDE 2.0 running. Okay, I got a little carried away in the preliminaries, but I had fun doing it, and I learned a lot about configuring XFree86. It was worth the time.

Building the new KDE wasn't especially hard, but it has a lot of steps. The first thing I had to do was to get the KDE snapshots, which came from ftp://ftp.kde.org/kde/snapshots/current/. As with XFree86, I did this before the mirrors had replicated the code, but you could improve your download speed and reduce the load on the KDE team's server by checking the mirrors first. I have also learned, after doing all of this manually, that someone has just released a set of RPMs for Caldera eDesktop 2.4. These can be found at ftp://ftp.kde.org/pub/kde/unstable/distribution/. I have not tried the RPMs (for one thing, I don't have eDesktop 2.4 yet) but they are another option if appropriate to your system.

You'll need to install the new QT 2.1 libraries from Trolltech first. Since I'm not using QT to develop commercial software, I downloaded the free version (licensed under the QPL) from Trolltech's Web site and installed it according to their directions (after first backing up what I had, which was 1.44). This is the step where you break compatibility with KDE 1.x, so be very careful to make a backup of QT! I untarred the new QT source under /usr/lib and thus ended up with it in /usr/lib/qt-2.1.0. Before running the build in that directory, you have to export QTDIR=/usr/lib/qt-2.1.0 or the configure will fail. Then you run ./configure -gif inside that directory, followed by the usual make step. After everything is done, you need to add the directory to /etc/ld.so.conf and then run ldconfig as root.

Next, you're ready to build KDE 2 itself. I picked /opt/kde2 as my destination directory for the install, but you can use any directory you like as long as you first export KDEDIR=xxxxx, where xxxxx is the directory of choice (no trailing slash). Don't use your KDE 1 directory.

KDE's source snapshots come with a file called compile_script, which you would think does a correct and complete build. It doesn't, or at least it never has for me. Fortunately, you can edit the script to make it work correctly. Unfortunately, it's not just a single change--you actually have to modify it several times during the process.

Start by adding "kde-qt-addon " (note trailing blank space!) at the beginning of the list of strings on the PACKAGES=.... line. You're now ready to run the script. Each time you run the script, you need to have your KDE 2 destination directory (not the file download directory) as the current working directory for your shell. If you don't do this, you will end up with an enormous mess! Run the script and pass its own directory to it as a parameter so it knows where to find the source code. For example, if you downloaded the .bz2 files to /download/newkde and you are installing to /opt/kde2, then the script command looks like this:

sh /download/newkde/compile_script /download/newkde

(Note the spaces after "sh" and after "compile_script".)

It will crunch along for anywhere from several minutes to an hour or more, depending on the speed and loading of your machine. Then, if you are as fortunate as me, it will die. When it does, look in your /opt/kde2 directory (or wherever you are installing) and see which was the last package it was working on. This can also be discerned from the "leaving directory ....." messages output at the end of the failed "make" sequence. Make that directory current, then run these two commands:

make
make install

This should succeed. What you've just done is to resume the original make at the point where it failed. Note that I'm assuming here that you suffer from the same errors I did--there just seems to be something wrong (memory leak or stack overflow, perhaps?) in the GNU development tools, but make is very smart about resuming a failed build.

If make install works successfully, then do a cd .. to get back to the main installation directory. This step is crucial!

Now go back and edit the compile_script again, and delete from the PACKAGES=.... line all of the packages which have been successfully built so far, including the one where you just intervened manually.

Repeat this process as many times as needed, until you have a full KDE 2 build. It took me about five hours to get through the whole thing, and I finished (finally!) at 4:30 a.m. The "kdemultimedia" package never would build for me, but it's nonessential so I finally just skipped it. There are also a couple of packages that aren't in the compile_script; I haven't gotten around to building these yet.

Step 4: Testing the Installation

The first time I tried this (with one of the April snapshots) I made a royal mess of my KDE configurations by letting KDE2 share user directories with KDE1. Bad idea. Instead, add the line:

export KDEHOME=$HOME/.kde2

to your /etc/profile script, so that KDE 2 will create its own fresh configuration directories. This keeps it from messing with your previous customizations, which are generally stored in $HOME/.kde for each user on the system.

Login again, or manually enter the above command, so that this variable is defined correctly for your current session. You'll also need to clone the "kde" command from the old KDE 1 installation into KDE 2's bin directory, at least if you're running Caldera. Other distributions may be different. The kde command looks at the /etc/X11/xinit/kdeinitrc file that you duplicated in the XFree86 installation step.

If you are running xfstt, the TrueType font server, and you upgraded to the new XFree86, now is the time to kill xfstt and start xfs (the new version of it) instead. Just type xfs & as root for now; later you can put this in rc.local or some other startup script.

Now, from a console-mode user prompt, just run kde and it should start up. You're ready to start having some fun with the latest code!

My First Impressions of KDE 2

I've only been running it for about eight hours as I write this, but so far there have been zero crashes of KDE as a whole. I've seen some applications refuse to start, or start then die with no message, but KDE itself seems relatively stable. There is no doubt, however, that this is beta level code and not a final release. Not all of the features that are shown on the menus are implemented yet, and some of what's there doesn't work right--or at all. Even the compile process, if you watched it carefully, issued warning messages about "really ugly hacks" and other TODO items that need to be fixed before the release date.

Konqueror, the built-in browser that can do local files and directories as well as Web and FTP sites, has been much improved in this beta. I used it to visit some web sites with fairly complex layout and frames, and I haven't yet seen a problem. The alpha version that I tested previously crashed a lot; so far the beta has not crashed at all. Figure 1 shows Konqueror viewing a local directory and the LinuxPlanet home page; the Task Manager and a couple of menus are also shown. Note the attractive marble texturing, one of several themes that are part of the distribution.

One problem that pervades my installation of KDE is that it is unable to view JPEG files. GIF and PNG work fine, but not JPEG. I don't blame the KDE team for this--I probably did something wrong during installation, or I need to update my libjpeg files. I'll work on this soon, because it's a real headache for Web access.

KDE 2 adds numerous graphical tools and toys. I haven't had a chance to look them all over yet, but Figure 2 shows KFractal, KPaint, and Katalog. Katalog is a thumbnailing tool for organizing images, and I'm looking forward to seeing what it will do in its released version. It looks as if it might be pretty useful for organizing clip art or other Web graphics. I couldn't get the Icon Editor to load, unfortunately.

The new system information tools, shown in Figure 3, provide detailed data on the processor, memory, X server, interrupts, I/O, and other details. I especially liked the memory graph. There is also an applet that runs in the KPanel and shows a live bargraph of memory and swap usage. The partition information wouldn't work for me; I don't think it's implemented yet, judging from the message that popped up.

Figure 4 shows some of the configuration dialogs for the desktop, KPanel, and the screen savers. I don't have the OpenGL support loaded yet, so not all of the screen savers would work for me. (Of course, that's not a KDE bug, and I know what I need to do to fix the problem.)

Kontrol, the KDE customizer, has many dialog panels available for controlling just about everything in the desktop environment. Not all of the features are implemented yet, but there are already a lot that are working. Figure 5 shows the font-selection dialog.

Finally, here's my old friend, KMail, in Figure 6. showing its main screen and the "Identity" configuration dialog. Guess what? The SMTP send now works perfectly! So, though I had to fight a lot of alligators to get here, the swamp is at last drained and dry, so to speak. One feature I really like in the new KMail is the ability to define multiple identities within a single Linux user account. That's very handy for people who need different taglines and reply-to addresses for business and personal use, for example.

Next Steps

I'll spend a few hours over the next week or so working on the problems I've already found, and reporting to the KDE team anything I can't fix. Then I have some definite plans on what I'd like to do in the new KDE 2.

For starters, I want to learn more about the KDE object model that has been added into this version. I have heard rumblings of Java bindings being written, or at least possible, and I'm intrigued. As an avid Java programmer, I like the idea of being able to do both cross-platform and natively-targeted applications in Java. Microsoft did something like this with DirectX, and I never objected to it until they started cramming it down everyone's throat with Visual J++ 6.0. But I like having the option as a programmer to use native tools where they make sense, and cross platform tools where they make sense. KDE Java bindings, if they really are under development, would do for Linux Java what Microsoft DirectX did for Java on Windows--except that in KDE it'll be an Open Source toolset.

Next, I need to get my sound and multimedia support working. I didn't have sound working on my prior version of KDE (I broke it during a kernel upgrade and hadn't gotten around to fixing the modules list yet), but I'd like to try the new audio server architecture under KDE2.

Finally, I think I might even be adventurous enough to fool around with KDevelop. I haven't seen it in action yet, but everything I've heard about it suggests that this C/C++ IDE is very promising and maturing rapidly. I need to refresh my long-disused C++ skills, and this just might give me the impetus I need.

I hope you've enjoyed this little romp on the wild side, living out on the bleeding edge with some pretty untested code and configurations. I won't claim to be an expert on what I've just done--but I certainly have learned a lot by doing it, and I intend to keep on learning as long as Linux and Linux software keep innovating. I suppose some people buy a computer to do useful work, or so I have been told. Not me--I'm having too much fun!

If you have suggestions of better ways to do things than what I've described here, by all means let me know by e-mail. When I do any follow-up articles on this topic, I'll include some of the most helpful suggestions. If you send me an idea, please let me know if I may use it in print and if you would like your name mentioned in the credits.

XFree86 4.0 and KDE2 can be a challenging installation, but over the past few days I've learned that they can be made to play together. I'm looking forward to what the future holds for both of these excellent Open Source projects, and I congratulate the teams on what has been accomplished so far.