2004-03-19
| Revision History | ||
|---|---|---|
| Revision 1.01 | 2004-03-19 | Revised by: KC |
| Initial Release, reviewed by LDP | ||
Copyright (c) 2004 by Kai Schlachter
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is located at http://www.gnu.org/licenses/fdl.html.
I especially want to thank Nico Schmoigl for helping me get my crashed system back up after I ran make install for glibc while my system was still fully running. This was the main reason I wrote this mini-HOWTO.
Thanks also go to all the other people who helped me along the way; getting the HOWTO in correct format, finding all the typos, etc.
In this HOWTO I will explain how you install a new version of glibc on your system.
I wrote this manual because I want to save others from the problems I encountered.
This HOWTO is a kind of guideline, made up from settings and ways of doing things that worked out for me. No liability for the contents of this document can be accepted. Use the concepts, examples and other content at your own risk. You are strongly recommended to make a backup of your system before major installations and backups at regular intervals.
If you have any suggestions, found another bug in some distribution and how to fix it, please let me know by writing me an e-mail: <linux_at_murphyslantech.de>.
Yes, that's a good question. Why would you need to install a new glibc? Well, there are several reasons:
you are a developer and you need the new functions of the library
you wanted to compile a new program that needs the new library
you like the thrill of errors and bugs in new versions ;-)
If you do not know what glibc is by now, don't worry! When I first had problems with a new program I wanted to compile, I only knew that my version of glibc was not sufficient for the compile. Now that I know more, I will try to explain in a very simple way what glibc does.
The glibc package contains a library written in the programming language of C. Libraries are a very useful thing in programming; instead of inventing the wheel from scratch for operations such as computing the square-root of a number, such common functions are stored in separate files—the so-called libraries. When a new version of a library is published it often contains some new functions, uses more efficient algorithms for already implemented functions, and so on.
This is the reason why some programs complain about an older version of glibc: the current version just does not contain all the functions the program needs in order to run.
I know this is not technically correct in all detail, but it gives you a basic understanding of the architecture behind.
As an installation of glibc is not an easy task. You need to do a lot of things in advance, especially in the event that something goes wrong. (That is what happened to me on my first glibc install, and I did not make any preparations.)
Basically, you need two different things: software that is already running on your machine (eg., pre-installed by your distribution) and packages of source-code for different programs.
Since you are going to substitute the basic library many programs rely on, you can imagine the problems that may occur.
For me, it so happened that everything went fine until I typed in make install. At about halfway through the installation process I got an error telling me that rm was not able to run, and I found out that even all the common commands like cp, ls, mv, ln, tar, etc., did not work; all told me that they were not able to find parts of the library they needed.
But there is help available. You can force the compilation of programs with the libraries compiled into them, so the programs do not need to look them up from the library.
For that reason, in this chapter, we will compile all the utilities we need for the install into a static version.
Get the newest version from: ftp.gnu.org/gnu/binutils; at the time of writing, this was version 2.14
Open the package:
tar xIvf binutils-2.14.tar.bz2 |
Change to the directory:
cd binutils-2.14 |
Configure the Makefiles:
./configure |
Compile the sources:
make |
Install them with:
make install |
If you run into trouble with the compilation of the binutils, referring to problems with gettext (indicated by errors like: "undeclared reference to lib_intl" or similar) please install the newest version, available from ftp.gnu.org/gnu/gettext.
If this does not help, try disabling the native-language support by using:
./configure --no-nls |
You don't need to build a static version of the binutils, though it would not hurt, but I encountered many systems running with very old versions and ran into errors almost every time, so I think it is a good idea to mention them here.
The make command is responsible for the compiling of the sources, calling gcc and all the other programs needed for a compile. Since you may need to compile something if a problem occurs with the new glibc, it is a good idea to have it static, otherwise it might not work after an error appears.
Download the source from ftp.gnu.org/gnu/make/; at the time of writing the current version was 3.80
Unpack the source, eg.:
tar xIvf make-3.80.tar.bz2 |
Change to the created directory:
cd make-3.80 |
Take care that the binaries are built static:
export CFLAGS="-static -O2 -g" |
Run the configure script:
./configure |
Compile the stuff:
make |
Install the binaries:
make install |
Make a check:
make -v |
Congratulations! You have compiled another static-linked program.
The core-utils are commands like: cp, rm, ln, mv, etc. In case of an error in the installation, these are an absolute requirement to help bring your system up again, so static binaries are really necessary here.
Again, download the source tarball from: ftp.gnu.org/gnu/coreutils/; at the time of writing, version 5.0 was current.
Unpack it:
tar xIvf coreutils-5.0.tar.bz2 |
Change to the directory:
cd coreutils-5.0 |
Take care that the binaries are built static:
export CFLAGS="-static -O2 -g" |
Configure the package:
./configure |
Compile the binaries:
make |
And install them:
make install |
Verify that the right core-utils are used:
cp --version |
Now that the binaries of these very elementary tools are static, you can be sure they will work every time you need them.
You have already used GNU tar to unpack all the programs compiled and installed so far. But maybe you need to compile another program which is needed by glibc after you had a crash, and in this situation (I experienced this myself!) it is very useful to have a working tar ready to unpack the missing programs. With tar, we also need to take care of the bz2 compression algorithm, which is not included in the normal source distribution of tar.
Get the source of GNU tar from ftp.gnu.org/gnu/tar; at the time of writing, version 1.13 was up-to-date.
As many source tarballs are compressed with bzip2, we would like to have the support built in, rather than working with pipes, so get the patch from: ftp://infogroep.be/pub/linux/lfs/lfs-packages/4.1/tar-1.13.patch.
Unpack the source by invoking:
tar xzvf tar-1.13.tar.gz |
Copy the patch to the source directory of tar:
cp tar-1.13.patch tar-1.13/ |
Apply the patch:
patch -Np1 -i tar-1.13.patch |
Set the compiler flags to make a static binary:
export CFLAGS="-static -O2 -g" |
Now we are ready to configure:
./configure |
Compile with:
make |
And as the next step, install the package:
make install |
Do a quick check to ensure the new version is being used from now on:
tar --version |
If you experience problems with the execution of make, try to turn off native-language support (nls). You may achieve this by invoking configure with the option:
--disable-nls |
Note: In this new version of tar, you must use the -j switch to decompress .bzip2 files, so instead of
tar xIvf anyfile.tar.bz2 |
tar xjvf anyfile.tar.bz2 |
I prefer Bash as my shell; if you use a different one, please be sure you have installed a static version of it before you install glibc.
Get Bash from: ftp.gnu.org/gnu/bash/. Download the newest version you can find; at the time of writing this was version 2.05b.
Unpack the source tree:
tar xzvf bash-2.05b.tar.gz |
Go to the directory:
cd bash-2.05a |
Set everything up for building a static version:
export CFLAGS="-static -O2 -g" |
Configure the makefiles:
./configure |
./configure --help |
Compile everything:
make |
Install the compiled binaries:
make install |
Make sure there is not another version laying around (like in my Suse-Linux: /bin/), by copying the file:
cp /usr/local/bin/bash /bin/ |
You now have installed a static version of Bash. For that reason, the binary is much bigger than usual, but it will run under all circumstances.
If you prefer to use another shell, you are free to do so, but make sure it is a statically-linked version. Feel free to email me a method to build the shell of your choice in a static version, and chances are good that it will be implemented in the next revision of this document.
Midnight Commander is a very useful file manager, supporting many nice features like transparent decompression of packed files, built-in copy, move and other common commands, as well as an integrated editor.
To compile this piece of software, you will need to have glib installed; in some distributions this is already the case. If you get an error in the make command saying that ld could not find glib, you will need to install this library first. You can get the sources from: ftp.gnome.org/pub/gnome/sources/glib/2.2/, and the installation is straight-forward.
Here are the steps to build Midnight Commander:
Get the source from http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/"; at the time of writing, the newest version was 4.6.0.
Unpack the sources:
tar xzvf mc-4.6.0.tar.gz |
Change to the directory you just created:
cd mc-4.6.0 |
Set up the configuration-files:
./configure |
Start compiling:
make |
Install everything:
make install |
Now we come to the most important thing: the glibc install.
There are several versions of glibc available, but not in all cases are new versions really better than the old ones. The best thing you can do to find out which works and which ones you should not use is to check out the different forums on the Internet. If you have someone to ask, talk to him about the topic. Maybe he already has installed the new version and might be able to tell you that version x.y.z is a PITA, but version a.b.c works really well!
I decided to install glibc-2.2.4, as I was told it works well, but it is your decision which one to choose.
Ok, now let's go to work:
Get the source from ftp.gnu.org/gnu/glibc/; as I said, I used version 2.2.4.
Unpack the source:
tar -xzvf glibc-2.2.4.tar.gz |
In addition, you will need a package called "linuxthreads," found in the linuxthreads directory on ftp.gnu.org. The file is called:
glibc-linuxthreads-2.2.4.tar.gz |
Copy the linuxthreads package to your glibc source directory:
cp glibc-linuxthreads-2.2.4.tar.gz glibc-2.2.4 |
Change to the glibc directory:
cd glibc-2.2.4 |
Unpack linuxthreads:
tar xzvf linux-threads-2.2.4.tar.gz |
Configure the package:
./configure --enable-add-ons=linuxthreads |
Afterwards, start the compilation of glibc:
make |
Now that the library is compiled, everything is ready for the installation, but things are not as easy this time.
To install glibc you need a system with nothing running on it, since many processes (for example sendmail) always try to use the library and therefore block the files from being replaced. Therefore we need a "naked" system, running nothing except the things we absolutely need. You can achieve this by passing the boot option
init=/bin/bash |
To start the "only-basics" system, reboot your computer and at the LILO prompt enter the kernel image-name you like to load and append
init=/bin/bash |
Grub is a newer bootloader, with enhanced support for different operating systems and and file system types (eg. it supports booting from reiserfs partitions). If you would like to know more go to: http://www.gnu.org/software/grub/, where you will find all the stuff you need.
If you already have Grub installed, you probably use the text-based front-end to select the kernel you prefer to boot. Grub has a nice feature—instead of returning to doing everything by hand, you can simply select your entry and type e, which will bring up an option menu. In this menu you will see the commands Grub executes prior to booting the kernel. Simply select the line saying
kernel="/where/your-kernel-is and-options-are" |
init=/bin/bash |
...You will find yourself in an absolute minimal bash-environment.
You will not even be asked to enter your username or password! At this time you are the ultimate super-user; no-one can get around you because the system is in single-user mode, so be careful what you are doing. There are no file-rights set or anything else!
Your prompt will probably look like this:
init-x.y# |
mount -o remount,rw / |
mount -t reiserfs /dev/md0 /usr/src |
Now you can go to the directory containing the source and type in:
make install |
If you like, now might be a good time to pray that everything works out fine... ;-)
If everything went through properly, you will return to your prompt after the installation without any error message. In all other cases, please see Chapter 5.
If everything goes fine, run:
ldconfig -v |
Congratulations! The library is successfully installed. Now type in: mount -o remount,ro / to ensure that all the data is written to the hard drive.
Now start the reboot:
exit |
Try booting your normal kernel. If everything turns out fine, you are ready to use the new library.
If you come to this section and you have followed all the instructions above, you probably encountered the problem of different Linux distributions, some of which do not keep stuff where it should normally be, but somewhere else. The Suse Linux distributions are most famous for such stupid quirks, but there may be others having similar problems. If you encounter such a thing and you find the cause for the trouble—and hopefully a solution—please let me know and I will add this to my HOWTO.
I think this section will never really be complete, but I will list some possible errors and solutions for these issues.
Sometimes you get configuration error telling you that, for example, a requirement is not met—typical for software or other library-packages which are to old. I encountered this with a series of programs, especially during the compile of all the static software. Normally there should be no problem: get an up-to-date version of the software or libraries needed and then compile them according to the description found in the source tree (usually called README, INSTALL or something similar).
But there are sometimes cases where this just does not want to work. For example, I experienced problems compiling a new version of my binutils (one of the reasons why I mention them in the requirements), as I needed to compile glibc. In return, the configure script for the binutils told me, "Your glibc is to old!" So I thought, Here the snake starts eating its tail. Thankfully there is a solution for this problem: if you can not take one big step, try taking smaller ones, but more of them.
In my distribution, a glibc with the version number 2.1.1 was included. To get around the error I tried to compile version 2.1.3, which was no problem. After I installed this version of the library, I tried to compile the binutils once more, and this time all the requirements were met.
If you encounter such a "loop," try to find out what version of the software required is the minimum, then download that version (I think that is one of the reasons why so many old versions are still lying around on the FTP servers). After successfully compiling and installing, try to build the software that complained about the version again; in most cases you should now be able to compile. It may be necessary that you continue to use this method to compile missing or old software. This is what I call "the long tail of the rat" or "domino-effect." You only wanted to do one thing, but you needed to do many more before you could make the move you wanted to. It might be very nasty, but there is one good side to it: afterwards you can be quite sure that many of the programs which were really old will replaced by the time you finish your installation.
The most common mistake is not to have a set of basic, static tools; in this case you can only use the command cd, but nothing else. This is the reason why in this HOWTO I have described in detail how to make those tools static.
The only tool not static is mount and, for good reason in my opinion, it is included in the package of linux-utils, which also contains login, passwd, etc. Since you are not able to use statically-linked versions in combination with PAM or other security-related software, it would be unwise to compile them statically under all circumstances. Of course you are free to do so if you are really sure about what you are doing.
The way back to a working configuration is quite simple if you have the static tools: go to the directory /usr/local/lib/ and move all the newly installed files into another location (eg. /usr/local/lib/storedaway). You may identify them by looking at their version number, which should be the same as the one from your glibc installation (in my example all files fitted to the scheme lib*-2.2.4), and of course by the creation date and time. It is quite uncommon that two different libraries have the same version number at the same time—I, myself, have never experienced such a thing—but just to be sure you do not delete something important to your system, check the date and time of creation. A very useful tool in this case is the Midnight Commander, if you have it installed.
You could try to remove the files ld-2.2.4.so and libc-2.2.4.so and run ldconfig -v afterwards, before removing all the crashed files. This will enable you to use at least most of your programs and in every case you will be able to run the Midnight Commander.
Do not forget to do at least one ldconfig -v after you have removed all the files.
A common cause for problems is that your distribution has stored all the library files in a different location than the newly-installed routine will use, thus it often happens that there are two versions running simultaneously, disturbing each other. In my case, lots of trouble was caused by a second copy of libc6.so lying around in /lib, a symbolic link from this file to the corresponding one in /usr/local/lib fixes this problem.