Choosing the Right Stage

When we asked you to choose for an installation medium (LiveCDs, existing distribution etc.) we explained you what the pros and cons are. One of those was choosing your stage: do you go for a full compilation (stage1), skip the bootstrapping (stage2) or start from a precompiled stade (stage3)?

Depending on your installation medium, you can still make your choice. Others will already have made the choice at the beginning of the installation. It is now time to install your choice of stage. But first we'll configure Portage with the compiler optimizations you want and feature support you need.

Configuring the Compile Options Introduction

To optimize Gentoo, you can set a couple of variables which impact Portage behaviour. All those variables can be set as environment variables (using export) but that isn't permanent. To keep your settings, Portage provides you with /etc/make.conf, a configuration file for Portage. It is this file we will edit now.

Fire up your favorite editor (in this guide we use nano) so we can alter the optimization variables we will discuss hereafter.

# nano -w /etc/make.conf

As you probably notice now, the make.conf file is structured in a generic way: commented lines start with "#", other lines define variables using the VARIABLE="content" syntax. Several of those variables are discussed next.

CHOST Although it might be interesting for non-stage1 users, they should not change the CHOST setting in make.conf. Doing so might render their system unusable. Again: only change this variable if you use a stage1 installation.

The CHOST variable defines what architecture gcc has to compile programs for. The possibilities are:

x86i386i386-pc-linux-gnux86i486i486-pc-linux-gnux86i586i586-pc-linux-gnux86i686 and above (incl. athlon)i686-pc-linux-gnualphaalpha-unknown-linux-gnuppcpowerpc-unknown-linux-gnusparcsparc-unknown-linux-gnuhppa
Architecture Subarchitecture CHOST Setting

The CFLAGS and CXXFLAGS variables define the optimization flags for the gcc C and C++ compiler respectively. Although we define those generally here, you will only have maximum performance if you optimize these flags for each program seperately. The reason for this is because every program is different.

In make.conf you should define the optimization flags you think will make your system the most responsive generally. Don't place experimental settings in this variable; too much optimization can make programs behave bad (crash, or even worse, malfunction).

We will not explain all possible optimization options. If you want to know them all, read the GNU Online Manual(s) or the gcc info page (info gcc -- only works on a working Linux system).

A first setting is the -march= flag, which specifies the name of the target architecture. Possible options are described in the make.conf file (as comments). For instance, for the x86 Athlon XP architecture:


A second one is the -O flag, which specifies the gcc optimization collection flag. Possible collections are s (for size-optimized), 0 (for no optimizations), 1, 2 or 3 for more speed-optimization flags (every class has the same flags as the one before, plus some extras). For instance, for a class-2 optimization collection:


Other popular optimization flags are -pipe (use pipes rather than temporary files for communication between the various stages of compilation) and -fomit-frame-pointer (which doesn't keep the frame pointer in a register for functions that don't need one).

When you define the CFLAGS and CXXFLAGS, you should combine several optimization flags, like in the following example:

CFLAGS="-march=athlon-xp -pipe -O3"
CXXFLAGS="${CFLAGS}"                  # Use the same settings for both variables
Default: Downloading from the Internet

Warn that you need networking. Download the required stage. Unpack on the mounted system.

Alternative: Using a Stage from the LiveCD

Warn that you need LiveCD. Unpack stage on the mounted system.