Changing GCC 2.96

path › xlife › columns › 20020316

Changing GCC 2.96

Xlife column for March 16, 2002:

Summary:
Find out how you can change what C/C++ compiler you're using or use several different versions at once.

1 Introducing C/C++ and compilers 1.1 C vs C++ 1.2 Why do I need a C compiler?
2 Introducing GCC 2.1 What kind of GCC is usually included?
3 What's wrong with GCC 2.96? 3.1 Don't believe everything you hear 3.2 What about the compatibility issue? 3.3 The bottom line
4 Actually changing GCC 2.96 to 2.95.3 4.1 Get GCC 2.95.3 4.2 Compilation and installation 4.3 Tell the system to use the new GCC 4.4 Tell source packages to compile with 2.95.3 4.5 Extra precautions for the paranoid
5 Using yet another GCC version 5.1 Using several GCC versions alternatively

1 Introducing C/C++ and compilers

First of all, you may wonder what a C/C++ compiler is. C and its more advanced relative, C++, are the programming language in which most Unix applications are written. It is preferred over other popular languages such as Perl mainly because, unlike them, it's not an interpreted language but a compiled one.

Interpreted language programs keep their source around as clear text and function by requesting the language interpreter program to interpret it for them each time they run. Compiled programs, on the other hand, use a compiler, a program which translates the source code into low-level machine readable code specific to a certain system architecture and sometimes to a certain machine alone (due to various hardware issues). The translations, known as compilation, is done only once, after which the program runs by itself, because it now contains only instructions that the operating system understands directly.

Performance and functionality issues aside, there are things you just can't do without compiled code. Besides, having a "standard" language coupled with GPL offers the posibility to reuse or inspire yourself from other people's work more easily. That's why C/C++ is the language of choice for the Unix world software development and which is why most of the programs you run at this very moment on your machine are based on C code.

1.1 C vs C++

Just sidetracking a bit: there is an ongoing dispute regarding C vs C++. The latter is more advanced and implements programming techniques known as object-oriented programming, but some people feel it ruins the purity of traditional C without important gain. Unless you're a programmer yourself, in which case you can make your own informed choice and form an oppinion, you don't care about this. Both versions of the language translate equally well into running programs when they're used right.

In the rest of this document by C I will understand both C and C++, in other words the C language in general.

1.2 Why do I need a C compiler?

Why do you need any C compiler on your machine? You do if you intend to ever install an application from the source code. It's possible to choose to stay out of trouble's way and only use pre-compiled ready made binary packages for all the applications you need, in which case you may never need GCC or any other compiler.

However, if you've ever found yourself in need for one, you noticed it can be a very important part of the operating system. If you want to hand-craft your system and only install apps from source you're doomed without a reliable compiler.

2 Introducing GCC

GCC (the GNU C Compiler) is considered one of the best C compilers around. As a consequence, most Linux distributions include a version of it.

2.1 What kind of GCC is usually included?

One of the good things about having people creating Linux distributions is that they take it upon themselves to thouroughly test all parts of the distibution before release.

The natural choice is to include a well established and stable version for every distro application, and GCC makes no difference, on the contrary even because it's one of the top-importance programs, up there with the Linux kernel.

3 What's wrong with GCC 2.96?

A little background on the issue: Red Hat decided to include GCC version 2.96.x in their 7.x distributions. At that time (and even now) GCC 2.95.3 was considered to be the last really stable and OK all around GCC version. 2.96 was a test branch of the compiler, which the GCC people had no intention to release as working software. When Red Hat's version of GCC indeed caused trouble by not working as expected, lots of people blamed Red Hat's choice and said they included a "broken GCC".

3.1 Don't believe everything you hear

First of all: a lot of people out of the Red Hat team are also active GCC developers. So it's not like they didn't have a clue about what they were doing. Not at all.

Second, and not less important: Red Hat's GCC 2.96 was not "broken". It's main problem was too tight C programming rules enforcement, which caused lots of applications' code to be rejected by it as being wrong. Thruth is that the standard of C coding is actually pretty tight, but lots of programmers are or want the freedom to be a little sloppy, so compilers usually include ways of righting the little mistakes themselves and only reject the big ones.

You can imagine suddenly finding yourself facing a compiler that will no longer forgive even the smallest mistakes. As a programmer it's tough, but for the user who can't understand why the apps that used to compile fine before won't do it anymore it's tougher. The word of mouth thus became "Red Hat's GCC is broken." The rest of it is hype.

3.2 What about the compatibility issue?

You may have heard there's also trouble regarding compatibility of code produced by GCC 2.96 with other versions. You can find out more about it on at the following two addresses, since we've already strayed far enough from the topic.

3.3 The bottom line

Red Hat wanted to provide a new version of GCC since 2.95.3 was getting rather old and GCC 3.x was still pretty much in a beta state. They had the skills and ability to pull it off. So they took 2.96 and added bugfixes and other stuff to improve it.

It did result in a better compiler, only it had that little "hard on the enforcement of rules" issue which caused all the trouble. They later fixed that too, and starting from Red Hat 7.2 (code name Enigma) the included GCC 2.96 is just fine. Some applications will still complain about it, but they will work.

4 Actually changing GCC 2.96 to 2.95.3

If you only have Red Hat 7.0 (possibly 7.1 too) around you can use it just fine and install it. You can then change GCC by using the instructions provided below. It's adviced you do the change first thing after system installation, so any apps you install after will use the new GCC if they need one.

At this moment, 2.95.3 is still the best choice of GCC around. (By best meaning less trouble for the average user.)

These steps have to be performed to make the change:

Get GCC 2.95.3
Compile and install it
Tell the system to use it instead of 2.96

4.1 Get GCC 2.95.3

You'll find it on GNU's GCC site. They provide mirrors there as well, that's why I don't just give an FTP address.

You'll eventually come accross several tarballs containing GCC 2.95.3. One of them is bigger and is called gcc-2.95.3.tar.gz, while the others have other names, such as gcc-something-2.95.3.tar.gz. Just get the big one. The others are smaller parts of the big one, for people who want specific parts of it packed separately.

Note that you don't need anything else. There's more to the C compiling environment (such as glibc, binutils, make and so on) but the ones provided by Red Hat are just fine. You only need to change the compiler itself.

Once you have the tarball unpack it by running these commands:

cp gcc-2.95.3.tar.gz /usr/src
cd /usr/src
tar -xvzf gcc-2.95.3.tar.gz

You are now ready for the next stage.

4.2 Compilation and installation

It should be pretty straight-forward, although it may take a while. Just run these commands (in the main source directory):

cd /usr/src
mkdir objdir
cd objdir/
/usr/src/gcc-2.95.3/configure --prefix=/opt/gcc-2.95.3
make bootstrap
make install

GCC prefers to be compiled from a different directory than the one the source is in. That's why we create another directory in another place, get inside it and run the compilation from there. There shouldn't be any trouble, and afterwards you'll find the new GCC placed in /opt/gcc-2.95.3.

It's a good idea to specify a special installation directory with --prefix (/opt is a good place to put it), because we don't want it to mix with the other GCC version already on the system.

Note that there won't be a step called "uninstalling GCC 2.96". You'll have it on the system too, just won't use it anymore. Since you need other packages for C compiling (see above) and they depend on what they know was the GCC version installed, it's more trouble than it's worth attempting to remove GCC 2.96.

4.3 Tell the system to use the new GCC

Right now you have a full GCC 2.95.3 installation in /opt/gcc-2.95.3 but it's no use, because the system and all the applications you attempt to compile will still use the old one. You need to tell them both to change that.

One thing you need to change is the PATH environment variable. This variable is set to certain values for every running application (including the shell or command prompt) and contains a list of directories where executables are placed.

First of all, you need to add /opt/gcc-2.95.3/bin to the PATH. Second, you must make sure the directory for the new GCC comes before the one for the old GCC (which is /usr/bin). If it doesn't, it's no use that you have your new GCC in the path, programs will always find the old one first and use that.

You do this by adding the following line to /etc/profile:

export PATH=/opt/gcc-2.95.3/bin:$PATH

The above is how we set environment variables on Linux systems. On your system it may be a little different. However, what we did is this: we changed PATH's value to our new GCC directory plus the old PATH value. The way we did it we are sure that the new GCC dir comes before any other, especially since /usr/bin makes it into the PATH earlier, in every user's .bash_profile file.

OK, the system knows about the new GCC now. Verify it by logging fresh into an account and run this:

gcc --version

You should see 2.95.3.

4.4 Tell source packages to compile with 2.95.3

Some source packages' configuration scripts will not use the PATH to reach the gcc executable, bit instead rely on another environment variable called CC (C Compiler).

You need to make sure it contains the right value, so add this at the bottom of your /etc/profile:

export CC=/opt/gcc-2.95.3/bin/gcc

You're all set now.

4.5 Extra precautions for the paranoid

Let's assume there's an application which will ignore both PATH and CC and instead decide to use /usr/bin/gcc directly. That's not nice and highly unlikely, but it could happen.

What we need to do is rename all GCC-related executables in /usr/bin to something else, which can't be known beforehand by an application, and put symlinks to the GCC of choice in their place. (You rename the old GCC executables, not delete them. You never know when something goes terribly wrong and you want them back.)

OK, so run this:

for prog in `ls /opt/gcc-2.95.3/bin`; do \
  mv /usr/bin/$prog /usr/bin/$prog.2.96 &> /dev/null \
  ln -s /opt/gcc-2.95.3/bin/$prog /usr/bin/$prog \
done

What we do here is this: we take each program name from /opt/gcc-2.95.3/bin; we rename it's counterpart in /usr/bin to something else (name.2.96); then we create a symlink named the same pointing back to the GCC dir of choice.

This way, even if an application is ill-behaving it will still reach the GCC it should, no matter how it goes about it.

5 Using yet another GCC version

It's not unthinkable that in the future you may want to install and use yet another GCC version (3.x will eventually take its rightful place in the Unix world) but still keep the old ones around for compatibility's sake.

What you do to get the newer GCC version compiled and installed may differ from what we've done for 2.95.3, or not. Regardless, you'll end up with, say, GCC 3.x in /opt/gcc-3.x.

You'll want to do the same as above to make the system and compiling applications use GCC 3.x instead of the others. As a small difference, you'll need to delete the executables in /usr/bin since they're just symlinks, and then make the new ones. Be careful, this works starting from the addition of a third GCC to the system. Otherwise, you may still have actual executables in /usr/bin.

5.1 Using several GCC versions alternatively

Say you have GCC 2.96, 2.95.3 and 3.x installed and you need an application to use one of them on-the-fly. Usually (if it's not one of those unpolite applications) you won't need to mess with the symlinks in /usr/bin every time. You just need to adjust PATH and CC for a moment (for the duration of the application's runtime).

Say you need to compile an application. Just redefine PATH and CC for a moment like in the following example. No need to change any configuration files like above.

PATH=/your-gcc-of-choice/bin:$PATH CC=/your-gcc-of-choice/bin/gcc ./configure
PATH=/your-gcc-of-choice/bin:$PATH CC=/your-gcc-of-choice/bin/gcc make
PATH=/your-gcc-of-choice/bin:$PATH CC=/your-gcc-of-choice/bin/gcc make install

< Back to the top | Read other columns | Choose what column I should write next! >