.comment: British Beer, American Politics, and glibc-2.2 - page 2

Yes, there is a connection

Some time ago I was told that there was a gcc flag that would optimize code for use on my K6-2 machine. I tried it and it didn't work, but I was using EGCS-1.1.2. Then, beginning about the first of the month, I was hitting all kinds of errors when I tried to compile the KDE2 CVS tree. EGCS is getting a little long in the tooth, anyway, so I thought I'd upgrade. Easiest way, seemed to me, was to grab the RPMs from Caldera's Linux Technology Preview directory, on their ftp site. I did that and was disappointed when the RPMs wouldn't install--the failed dependency was glibc-2.2.

There were no glibc-2.2 RPMs in the LTP directory. In fact, far as I knew, there was no actual glibc-2.2 at all. A visit to the gnu site taught me that glibc-2.2 had just been released, and the source could be downloaded.

Now. It was not long ago that Linus suggested on the kernel mailing list that people who compile their own glibc probably have a screw loose. And I've compiled earlier versions of gcc myself several times in the past, uneventfully, and know that it can be done against glibc-2.1. The sensible thing, then, would have been to download the source for gcc-2.95 and compile it. But, as in Florida, things were following their own twisted path here. I had the gcc-2.95 RPMs. They required glibc-2.2. If I were to get glibc-2.2 I would have to build it myself. Case closed.

When you build glibc, the INSTALL file tells you to read the FAQ. It takes a little while, and it requires a lot of concentration, but it's worth it. The build process requires a recent version of gnu make and, on my machine, a couple of other upgrades. The Caldera LTP directory had those, so they were no big deal.

There are a few things that are a big deal. One is the necessity of switching to single-user mode and closing any apps you don't absolutely need to have running. Another is to run make check after you think you've compiled the new glibc. If the tests do not complete successfully, track down and solve the problem, recompile, run make check again, and when and only when all the tests are successful dare you "make install." (I built using the prefix /usr. I wanted to switch to the new glibc entirely. Besides, this was a Really Good Chance to break my machine.) Yet another necessity is to back up your /usr/include directory. Once you've installed the new glibc, shut down and reboot, thereby minimizing confusion to running applications.

I was a little surprised that when I rebooted, I was able to start and run KDE2 with no problem. And, I realized, there was a bonus: my new glibc-2.2 had been built against linux-2.4.0-test 10; my 2.1 had been built using linux-2.2.14 includes.

So now I could install the gcc-2.95-2 RPMs I had. The installation went uneventfully.

Now it was time for the test: Building a current KDE2 CVS.

It didn't even make it through configuration of the first package. Configure told me this:

"checking for libXext... no

configure: error: We need a working libXext to proceed. Since configure can't find it itself, we stop here assuming that make wouldn't find them either."

Hmmm. Well, what do we do here? I checked and libXext was there, where it was supposed to be, in /usr/X11R6/lib. What now?