.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
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?