# Stage 1/3 Installation Guide for 2005.0 and GCC 3.4.4

## Bob P

NOTICE:  This version of the Stage 1/3 Guide is DEPRECATED.  The current version is located >> HERE <<.

-----------------------

Experimental: Stage 1/3 Installation for Gentoo 2005.0 and GCC 3.4.4

Just as you'd expect, every time that a toolkit component gets upgraded, something breaks.  It should come as no surprise to a seasoned Gentoo user that the usual suspects are the ones causing problems.  This thread is an Update to the Stage 1/3 NPTL Installation Method for Gentoo 2005.0 and GCC 3.4.3 to add support for the GCC 3.4.4 compiler.

WARNING:  This is an ADVANCED and EXPERIMENTAL installation method that is designed to include support for the Stage 1/3 Guide using GCC 3.4.4.  This experimental guide is designed to avoid the problems typically encountered when using GCC 3.4.4, but it is not thoroughly tested and is not guaranteed to work;  Many ebuilds are plagued by the retention of static libraries, and the problems that they cause are caused by bug-ridden ebuilds, not by a deficiency in the Stage 1/3 Installation Method itself.  

Gentoo users who are willing to experiment with adapting the Stage 1/3 Installation Method to work with GCC 3.4.4 are encouraged to post their feedback and links to their ebuild bug reports here so that the Guide can be refined to include support for GCC 3.4.4.

Faster than a Speeding Bullet... 

More Powerful than a Locomotive!

How To Build a Fast and Bulletproof Gentoo System --  Stage 1 NPTL Installation on a Stage 3 Tarball Using GCC 3.4.4

Copyright (c) 2005 Bob P and The Jackass! Project.  All Rights Reserved.

Background

The Stage 1/3 Installation Method was developed for Gentoo 2004.3 because at that time any Gentoo installation that was performed with anything other than a Stage 3 tarball suffered from two problems:  Circular dependencies within the base system, and the potential to leave behind unwanted files from the stage tarball because /var/db/pkg is incomplete.

As rac noted, "There are some 80+ packages in a stage1ball that are not listed in /var/db/pkg. Why? When you do your "emerge system", you would want your new toolchain to be used to compile all software. If portage sees that a particular version from the stageball is still current, it will omit it. The solution that somebody apparently chose was to make portage forget that most of this software is installed at all, which has the unfortunate side effect of making portage be unable to clean it when your "emerge system" finishes."

It seemed that there were some good reasons to never install from a Stage 1 tarball, and some good reasons to always install from a Stage 3 tarball.  The good news is that you can perform a Stage 1 installation using a Stage 3 tarball and have the best of both worlds.

With the advent of Gentoo 2005.0 the situation has improved markedly for users who wish to perform Stage 1 installs.  The /var/db/pkg problem has been resolved, but unfortunately some of the circular dependency problems remain.

Another reason to continue to perform Stage 1/3 installs relates to the system toolkit.  Unfortunately the GCC 3.4.4 toolkit components remain testing branch ebuilds.  As such, Gentoo 2005.0 continues to ship with a stable branch GCC 3.3.5 compiler.  Until such time that the GCC 3.4.4 compiler is reclassified into the stable software branch, the Stage 1/3 installation method will continue to be helpful to those users who wish to upgrade to a GCC 3.4.4-based toolkit.

Objective

This Installation Guide will describe how to perform a "Stage 1 on 3" installation of Gentoo on a Pentium-class x86 platform using 2005.0 installation media, a single CD-ROM drive and a single EIDE hard disk.  It will take advantage of the latest 2.6 kernels, NPTL threading, udev, and the latest GCC 3.4.4 compiler.

As you read this, you might be thinking: "Why a Pentium-class PC?"  Depending upon how you look at it, the answer can be simple or complex; The simple answer is that a Pentium-class PC was the only computer that I had left when I was developing this Guide that didn't already have Gentoo installed on it.  As I wrote the original version of this Guide I was working on a project to turn that PC into a linux-based a router.  

The complex answer relates to compatability of this installation method on a heterogeneous group of PCs;  A pentium processor is probably the most recent platform that is a common ancestor for all of the x86-class processors (AMD or Intel) that Gentoo is likely to run upon.  

When you follow this Guide, please resist the temptation to blindly follow it unless you are installing on a system that has a Pentium processor.  You should always choose the correct tarball and CHOST setting for your processor. 

To perform a 2005.0 Stage 1/3 Installation with GCC 3.4.4, follow these steps:

1.  Download and Burn the Minimal Installation CD.   The .ISO image required for the hardware used in this example is 

```
http://gentoo.osuosl.org/releases/x86/2005.0/installcd/install-x86-minimal-2005.0.iso
```

2.  Boot using the Minimal Installation CD.  At the "boot:" prompt, press <Enter> to select the default gentoo kernel.

3.  Configure LAN Card.  We're assuming that your LAN card has been recognized and that you can obtain a LAN connection via DHCP.  

```
# dhcpcd eth0
```

4.  Configure Your Hard Disk

4.1  View the Hard Drive's Operational Parameters.  In this example we will assume that only one hard disk will be installed on the system.  It will be recognized by Gentoo as /dev/hda.  We will start off by viewing the default disk parameters at boot:

```
 # hdparm /dev/hda 

/dev/hda: 

multcount    = 16 (on) 

IO_support   = 0 (default 16-bit) 

unmaskirq    = 0 (off) 

using_dma    = 1 (on) 

keepsettings = 0 (off) 

readonly     = 0 (off) 

readahead    = 256 (on) 

geometry     = 16383/255/63, sectors = 120034123776, start = 0

 # hdparm -i /dev/hda 

/dev/hda: 

Model=WDC WD1200JB-00GVA0, FwRev=08.02D08, SerialNo=WD-WMAL92634373

Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq}

RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74

BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16

CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648

IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}

PIO modes:  pio0 pio1 pio2 pio3 pio4

DMA modes:  mdma0 mdma1 mdma2

UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5

AdvancedPM=no, WriteCache=enabled

Drive conforms to: device does not report version:

* signifies the current active mode 
```

4.2  Tweak the Hard Disk Parameters with Hdparm.   In this example we're using a WD1200JB.  Its possible to get a little better performance out of this drive by issuing a few parameters with hdparm.  The following parameters work well with this drive:

```
# hdparm -a256A1c1d1m16u1 /dev/hda

/dev/hda:

setting fs readahead to 256

setting 32-bit IO_support flag to 1

setting multcount to 16

setting unmaskirq to 1 (on)

setting using_dma to 1 (on)

setting drive read-lookahead to 1 (on)

multcount    = 16 (on)

IO_support   =  1 (32-bit)

unmaskirq    =  1 (on)

using_dma    =  1 (on)

readahead    = 256 (on)
```

4.3  Test the Hard Drive's Performance.

Typical results for a Pentium-class PC without UDMA:

```
# hdparm -tT /dev/hda 

/dev/hda: 

Timing cached reads:   144 MB in  2.04 seconds =  70.60 MB/sec

Timing buffered disk reads:   26 MB in  2.65 seconds =    9.81  MB/sec
```

Typical results for a Pentium 3 with UDMA66:

```
# hdparm -tT /dev/hda 

/dev/hda: 

Timing cached reads:   520 MB in  2.01 seconds =  258.75 MB/sec

Timing buffered disk reads:   114 MB in   3.01 seconds =  37.90  MB/sec
```

4.4  Partition the Hard Drive

4.4.1  Display the Partition Information

Technically, the syntax of this command is used to change the partition information, but on an unpartitioned drive it will display the partition information that is available:

```
# fdisk /dev/hda 

The number of cylinders for this disk is set to 14593.

There is nothing wrong with that, but this is larger than 1024,

and in certain setups could cause problems with:

1) software that runs at boot time (e.g., old versions of LILO)

2) booting and partitioning software from other OSs

   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p 

Disk /dev/hda: 120.0 GB, 120034123776 bytes

255 heads, 63 sectors/track, 14593 cylinders 

Units = cylinders of 16065 * 512 = 8225280 bytes 

   Device Boot Start End Blocks Id System 

Command (m for help): 
```

4.4.2  Plan Our Partition Scheme:

To keep it simple, we're going to use the following partition scheme.  I'll leave out the details, assuming that you know how to partition your hard disk.

```
Partition File System    ID  Size      Description

/dev/hda1 ReiserFS 3.6   83  100 MB    Boot partition

/dev/hda2 (swap)         82  512 MB    Swap partition

/dev/hda3 ReiserFS 3.6   83  Remainder Root Partition
```

4.4.3  Partition the Hard Disk  (Boring details omitted in the interest of brevity)

4.4.4  Verify the partition configuration.

```
Disk /dev/hda: 120.0 GB, 120034123776 bytes

255 heads, 63 sectors/track, 14593 cylinders 

Units = cylinders of 16065 * 512 = 8225280 bytes 

Device     Boot   Start    End     Blocks    Id  System 

/dev/hda1    *        1     13     104391    83  Linux

/dev/hda2            14     76     506047+   82  Linux swap

/dev/hda3            77  14593  116607802+   83  Linux
```

4.4.5  Exit Fdisk and Save the Partition Layout  Press "w" to write the partition table to disk and exit fdisk.

```
Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.

Syncing disks

```

4.5  Installing File Systems.  This example covers the installation of Reiser FS 3.6 on the /boot and /root partitions, and swap on the /swap partition.

4.5.1  Install Reiser FS on /dev/hda1 and /dev/hda3:

```
# mkreiserfs /dev/hda1 && mkreiserfs /dev/hda3
```

You will need to answer "Y" when asked if you want to continue installing Reiser FS on the hard disk.

4.5.2  Install the swap partition on /dev/hda2:

```
# mkswap /dev/hda2 && swapon /dev/hda2
```

4.6  Mounting the File Systems.  Mount the partitions using the "mount" command.  

```
# mount /dev/hda3 /mnt/gentoo

# mkdir /mnt/gentoo/boot

# mount /dev/hda1 /mnt/gentoo/boot
```

5.  Installing the Gentoo Installation Files. 

5.1  Download the Stage 3 Tarball from the Internet.  

Go to the gentoo mount point on your hard disk:

```
# cd /mnt/gentoo
```

We will need to download 2 files from the mirrors:  The Stage 3 tarball and its checksum file.  These files are located on the mirrors in the following directory: /releases/x86/2005.0/stages/x86/

We will download the following four files using the "wget" command at the bash prompt.  The entire command must be typed on one line:

```
# wget http://gentoo.osuosl.org/releases/x86/2005.0/stages/x86/stage3-x86-2005.0.tar.bz2

# wget http://gentoo.osuosl.org/releases/x86/2005.0/stages/x86/stage3-x86-2005.0.tar.bz2.md5
```

If you need to check the list of Gentoo Mirrors, Click Here.  

(If your architecture is not x86 you will need to change the path and filename to suit your needs.)

5.2  Verify the md5sum of the Tarballs.  

```
# md5sum -c stage3-x86-2005.0.tar.bz2.md5

stage3-x86-2005.0.tar.bz2: OK
```

5.3  Unpack the Stage 3 Tarball.  Unpack the Stage 3 tarball using the following command.

```
tar -xjpvf stage3-x86-2005.0.tar.bz2
```

Now is a good time to take a break to re-dose with some caffeine, as this will take a little while...

5.4  Installing Portage 

5.4.1  Download a Fresh Portage Snapshot from the Internet. 

```
# wget http://gentoo.osuosl.org/snapshots/<most_recent_snapshot>.tar.bz2
```

5.4.2  Extract the Portage Snapshot

```
tar -xjvf /mnt/gentoo/<portage_snapshot>.tar.bz2 -C /mnt/gentoo/usr
```

The Portage snapshot files are named in the format "portage-YYYYMMDD.tar.bz2", where YYYY, MM, and DD represent the numbers of the year, month, and day that the snapshot was created.  As I write this Installation Guide, the most recent portage snapshot is portage-20050101.tar.bz2, so the commands to download, verify and extract the snapshot would look like this:

```
# wget http://gentoo.osuosl.org/snapshots/portage-20050326.tar.bz2

# wget http://gentoo.osuosl.org/snapshots/portage-20050326.tar.bz2.md5sum

# md5sum -c portage-20050326.tar.bz2.md5sum

# tar -xjvf /mnt/gentoo/portage-20050326.tar.bz2 -C /mnt/gentoo/usr
```

Some of these steps will take a while to complete.

6.  Installing the Gentoo Base System

6.1  Copy DNS Information  Copy the DNS information in /etc/resolv.conf to ensure that networking works in our new Gentoo environment.  

```
# cp -L /etc/resolv.conf /mnt/gentoo/etc/resolv.conf 
```

6.2  Mount the proc filesystem  We will mount the /proc file system to allow our Gentoo installation to use kernel-provided information within the chrooted environment.  

```
# mount -t proc none /mnt/gentoo/proc

# mount -o bind /dev /mnt/gentoo/dev 

# cp /proc/mounts /mnt/gentoo/etc/mtab
```

6.3  Chroot into the New Environment

```
# chroot /mnt/gentoo /bin/bash

# env-update

# source /etc/profile
```

6.4  Set the Date and Time

6.4.1  Set the Correct Date and Time. 

The date command uses the syntax MMDDHHMMYYYY, where MM is the month, DD is the day, HHMM is the time, and YYYY is the year.  As I type this, it is Sunday March 27, 2005 at 19:30:

```
# date 032719302005

Sun Mar 27 19:30:00 Local time zone must be set--see zic manual page 2005
```

6.4.2  Set the Time Zone Symlink.

This example displays the available time zone selections for the Western Hemisphere:

```
# ls /usr/share/zoneinfo/America
```

I'll set the local time zone to Central Time because I live in Chicago.  To do this, I first remove the symlink to the default time zone, and then replace it with a symlink to my local time zone:

```
# rm /etc/localtime 

# ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime

Sun Mar 27 19:32:50 CST 2005
```

6.4.3  Get it Right for Daylight Savings Time.

The previous example showed how to select a city when setting the timezone symlink.  It is my opinion that you should always choose a city that is in your time zone, and use the city to set the time zone symlink.  You should NEVER choose a time zone as your symlink for the setting the time zone.  Here's why:

I live in Chicagoland.  By setting the timezone symlink to the nearest major city, Chicago, I don't have to worry about implementing Daylight Savings Time.  Linux is smart enough to spring forward and fall back so that no changes to the system time are necessary on my part.  This past weekend, when Chicago changed from Central Standard Time to Central Daylight Time, I watched with glee as the clocks on all of my linux PCs ticked from 01:59:59 CST to 03:00:00 CDT.  (Just in case you were wondering, THAT is confirmation that I am a basement-dwelling linux g33k!)  If I had made the mistake of setting the timezone symlink to CST, then linux would have kept my PC's clock on CST, even though the city that I live in had switched to CDT.  In this case, I would either have to manually change my clock over from CST to CDT, or learn to live with a PC who's clock is off by an hour.  

6.5  Configuring the USE Flags, Portage Options, and Compile Options: /etc/make.conf

In this example, we're compiling for the x86 architecture and a Pentium-class i586 subarchitecture.  Our CHOST setting will be i586-pc-linux-gnu.  Do not blindly follow the Guide and use this setting unless you are building for a 586-class computer!  Use the appropriate tarball, CHOST setting, and architecture specifications for your processor.

This Guide uses a minimalist setting of the USE variable.  You are free to add additional USE flags as needed for your specific system requirements, but it is recommended that you do not add them to /etc/make.conf until after you have completed the entire installation.

Please note:  The specification of the "nptl" and the exclusion of the "nptlonly" USE flag is intentional, in order to provide both NPTL threading support in glibc as well as fallback support for linuxthreads.  Use of the "nptlonly" USE flag is NOT recommended!  The use of hardened GCC 3.4.4 is not recommended on any x86 systems except AMD64.

```
# cat /etc/make.conf

CHOST="i586-pc-linux-gnu"

CFLAGS="-O2 -march=pentium -fomit-frame-pointer -pipe"

CXXFLAGS=${CFLAGS}

ACCEPT_KEYWORDS="x86"

PORTAGE_TMPDIR=/var/tmp

PORTDIR=/usr/portage

DISTDIR=${PORTDIR}/distfiles

PKGDIR=${PORTDIR}/packages

PORT_LOGDIR=/var/log/portage

PORTDIR_OVERLAY=/usr/local/portage

GENTOO_MIRRORS="<your mirror goes here> http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"

SYNC="rsync://rsync.gentoo.org/gentoo-portage"

RSYNC_RETRIES="3"

RSYNC_TIMEOUT=180

MAKEOPTS="-j2"

PORTAGE_NICENESS=3

AUTOCLEAN="yes"

FEATURES="ccache distlocks sandbox userpriv usersandbox"

CCACHE_SIZE="512M"

RSYNC_EXCLUDEFROM=/etc/portage/rsync_excludes

USE="nptl"

```

6.6  Additional Portage Configuration

6.6.1  Create Portage Directories

The sample /etc/make.conf listed above specifies directories for Portage log files and overlays that are not included as part of a standard Gentoo installation.  If you are going to use the logging and overlay functions listed in the sample make.conf file, then you will need to create two additional directories on your system.

```
# mkdir /var/log/portage

# mkdir /usr/local/portage
```

6.6.2  Package Keywords - Enabling GCC 3.4.4 in the Stable Branch

Skip this step and proceed to the next section if you have configured your system to use the "~x86" testing branch.

At the time that I write this guide, GCC 3.4.4 is part of the unstable or "testing" branch in Portage.  If you will be using the "x86" stable branch of the software, then we need to configure Portage to enable the use of GCC 3.4.4 and some other toolkit components, even though they are currently classified in the testing branch.  

To configure a stable branch system to utilize a testing branch ebuild, we need to let Portage know that we have approved this subset of the testing branch for use on our system.  This is accomplished by specifying the name of the package and the applicable keyword in the /etc/portage/package.keywords file.  We will enable support for four testing branch ebuilds in our system. 

```
# cat /etc/portage/package.keywords

~sys-devel/gcc-3.4.4 ~x86

sys-devel/gcc-config ~x86 

sys-libs/libstdc++-v3 ~x86

sys-libs/glibc ~x86

sys-devel/binutils ~x86

sys-libs/timezone-data ~x86
```

  6.6.3  Update the Portage Tree

We will now update our portage snapshot to include the current portage tree.

```
emerge --sync
```

6.7 Activate User Locales  

When compiling glibc (we'll do this in an upcoming step), Gentoo's default behavior is to compile a full set of all of the available user locales.  We will activate the userlocales local USE flag to limit the compilation of userlocales to those that we specify.  Limiting the scope of userlocales will save us a tremendous amount of time while compiling glibc.  (While we're editing this file, we'll also add "ithreads" as a package-specific USE flag for perl and libperl to allow interpreter level threading.  This flag is optional but recommended.)

6.7.1  Activate the userlocales USE flag for glibc

```
# cat /etc/portage/package.use

sys-libs/glibc userlocales

sys-devel/libperl ithreads

dev-lang/perl ithreads
```

6.7.2  Specify the user locales to build. 

Create the /etc/locales.build file with your favorite editor.  I'm located in the USA, so I'll use the following values.

```
# cat /etc/locales.build

en_US/ISO-8859-1 

en_US.UTF-8/UTF-8 
```

 7.  Building the Toolkit 

7.1  Building the Toolkit: GCC 3.3.5

To enable NPTL support we are required to use a 2.6 kernel and linux26-headers. Linux26-headers is now contained in the 2005.0 Stage 3 tarball, so it is no longer necessary to manipulate the linux headers as it was when installing with 2004.3 media.

```
# env-update && source /etc/profile

# emerge gcc-config glibc binutils libstdc++-v3 gcc
```

This is a good opportunity to take an extended break, as these instructions will take quite some time to complete.

7.2  Re-Building the Toolkit:  GCC 3.4.4

After emerging a new version of GCC, we need to pause for a moment and think about what we've done.  We've just used GCC 3.3.5 and a toolchain built with GCC 3.3.5 to compile GCC 3.4.4.  Before we spend any more time building our Gentoo system we should rebuild the entire toolchain, re-compiling it so that we have GCC 3.4.4 that was built with GCC 3.4.4.  

Before we do this we need to examine /etc/make.conf and make changes to the CFLAGS statements in order to take advantage of the new performance-enhancing features of GCC 3.4.4.  After making necessary updates to /etc/make.conf we need to rebuild the toolkit using the new GCC 3.4.4 compiler.  The result will be a 3.4.4 tooklit, compiled by a 3.4.4 toolkit that was built with a 3.3.5 toolkit.  Clear as mud?   :Rolling Eyes: 

7.2.1  Updating make.conf

Here are some settings for /etc/make.conf that may be worth considering.  They are the actual CFLAGS that I used to build my systems and have proven reliable on multiple installations.  They include extreme levels of code optimization (notice the -O3 flag), and some very safe and stable performance-enhancing CFLAGS.  Depending upon your individual hardware, you may have to simplify some of the CFLAGS settings.  Note that the referenced architecture in this example is Intel Pentium.

```
CFLAGS="-O3 -march=pentium -fforce-addr -fomit-frame-pointer -ftracer -pipe" 

CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
```

If you don't feel comfortable using such extreme levels of optimization, you can ease-up on the CFLAGS settings and fall back to a less-optimized system.  This will save you some compile time, at the expense of some system performance.  You'll still be getting most of the benefits of GCC 3.4.4, so this isn't a bad compromise.  This may be a better approach for those who don't want to be on the bleeding edge or don't want to spend time troubleshooting.

```
CFLAGS="-O2 -march=pentium -fomit-frame-pointer -pipe" 

CXXFLAGS=${CFLAGS} 
```

7.2.2  Configuring the Default C Compiler

Although we have emerged GCC 3.4.4, it has not been automatically installed as our default compiler.  If you have any doubts about this, take a quick peek at the output of "emerge info" or "gcc-config -l".  Although GCC 3.4.4 has already been emerged, GCC 3.3.5 is still installed as out default compiler:

```
# gcc-config -l

1] i686-pc-linux-gnu-3.3.5.20050130-r1

[2] i686-pc-linux-gnu-3.3.5.20050130-r1-hardened

[3] i686-pc-linux-gnu-3.3.5.20050130-r1-hardenednopie

[4] i686-pc-linux-gnu-3.3.5.20050130-r1-hardenednopiessp

[5] i686-pc-linux-gnu-3.3.5.20050130-r1-hardenednossp

[6] i686-pc-linux-gnu-3.4.4 *

[7] i686-pc-linux-gnu-3.4.4-hardened

[8] i686-pc-linux-gnu-3.4.4-hardenednopie

[9] i686-pc-linux-gnu-3.4.4-hardenednopiessp

[10] i686-pc-linux-gnu-3.4.4-hardenednossp

```

Change the default compiler to gcc 3.4.4 by issuing the following command.  Note that the numbers may have changed.

```
# gcc-config 6
```

7.2.3  Updating the System Environment

An additional command updates our system environment:

```
# env-update && source /etc/profile
```

7.2.4  Rebuilding the System Toolkit

Now its time to rebuild the toolkit.  We'll start off by recompiling glibc, binutils, gcc, and by updating portage.  This will rebuild our GCC 3.4.4 compiling toolkit (which had previuosly been compiled with GCC 3.3.5) with the GCC 3.4.4 compiler, taking advantage of our new USE flags and CFLAGS compiler settings.  

```
# emerge glibc binutils libstdc++-v3 gcc portage 
```

Upon completion of the rebuild of the compiling toolkit, we will recompile the entire system to assure that our entire toolkit has been compiled using GCC 3.4.4 and our hardware-specific settings.  

The result will be a 3.4.4 tooklit and an entire system that is built with a 3.4.4 toolkit, that was built with a 3.4.4 toolkit.   :Wink: 

```
# emerge -e system && emerge -e system 
```

7.2.5  Prune the GCC Compiler

Now that GCC 3.4.4 has been installed as the default compiler and our system has been rebuilt, we can prune GCC 3.3.5 from our system by issuing the following commands.  First, verify that GCC 3.4.4 has indeed been installed as the default compiler using the "l" parameter with gcc-config.  (Just to avoid any confusion, the parameter used is a lower case "L", not the number "one".)  Then, after confirming that GCC 3.4.4 has been installed as the default compiler, prune GCC 3.3.5 from your system.

```
# gcc-config -l

# emerge -P gcc
```

7.2.6  Summary

Although these command have been broken down into separate steps for the purpose of clarity, they can be concatenated into three steps.  The one-liners in Steps 1 and 3 will take quite some time to complete, and represent good opportunities for you to take an extended break while Gentoo does its thing.

Step 1:

```
# env-update && source /etc/profile && emerge gcc-config glibc binutils libstdc++-v3 gcc 
```

Step 2: update your USE flags and CFLAGS in /etc/make.conf 

Step 3:

```
# gcc-config 6 && env-update && source /etc/profile && emerge glibc binutils libstdc++-v3 gcc portage && emerge -e system && emerge -e system && emerge -P gcc
```

8.0  Building the World

8.1  Emerge Ccache (Optional)

Now that our toolkit has been built, we'll emerge the ccache program.  Ccache is a compiler cache that will help to reduce compile times when previously compiled programs are being recompiled.  It will not effect the time required to compile programs on the first pass, so this is an optional step.  (Note: the ccache_size was set to 512 MB in the sample make.conf.  If you have sufficient disk space, and you're planning on emerging a bloated window manager like Gnome or KDE (or if you are performing an emerge -e system or an emerge -e world), then you may want to increase the to something like ccache_size="2G".)

```
# emerge ccache
```

8.2  Emerging Programs

Now its time to add a few useful packages to our world profile:

```
# emerge syslog-ng xinetd grub vixie-cron reiserfsprogs sysfsutils dhcpcd hotplug coldplug gentoolkit

# emerge --nodeps acpid ntp
```

8.3  Updating the Environment  

Now we'll add these services to the default runlevel.  Here two ways to accomplish this task that are functionally equivalent.  Choose the one you like best.

```
# rc-update add syslog-ng default 

# rc-update add net.eth0 default 

# rc-update add vixie-cron default 

# rc-update add xinetd default 

# rc-update add sshd default 

# rc-update add hotplug default 

# rc-update add coldplug default 

# rc-update add acpid default

# rc-update add ntp-client default
```

or if you're an ub3r-g33k, try this cool bash loop  :Cool:   that saves alot of typing:

```
for x in syslog-ng net.eth0 vixie-cron xinetd sshd hotplug coldplug acpid ntp-client ; do rc-update add $x default ; done 
```

8.4  Configuring the NTP Client  

In the previous steps we emerged a Network Time Protocol client to allow us to use NTP time servers to synchronize our system clock.  In this step we'll configure the ntp-client to eliminate clock skew:

```
# ntpdate -b -u pool.ntp.org
```

9. Kernel

9.1  Downloading the Kernel 

The decision to enable NPTL support requires that we use a 2.6 kernel.  You are free to choose any flavor of 2.6 kernel that you like.  In this example, we'll be using the Gentoo (Development) Sources kernel.  Note that a 2.4 kernel will not work properly with this Installation Guide. 

```
# emerge gentoo-sources
```

9.2  Building the Kernel Symlink

```
# rm /usr/src/linux

# cd /usr/src

# ln -s linux-2.6.12-gentoo-r6 linux 
```

9.3  Configuration 

9.3.1  Enable udev Support  

Edit your /etc/conf.d/rc file so that it contains the following statements:

```
RC_NET_STRICT_CHECKING="no" 

RC_DEVICES="udev" 

RC_DEVICE_TARBALL="no"  
```

 9.3.2  Configure Kernel Options

If you're following this Installation Guide, we're going to assume that you want the best performance from your system, and that you'll be using a custom-compiled kernel instead of genkernel.  When configuring your kernel, be sure to include support for hotplug firmware loading.  Also be sure to remove devfs filesystem support, as we are designing udev support into our system.

Configure the kernel:

```
# cd /usr/src/linux

# make menuconfig  
```

9.3.3  Compiling the Kernel

To compile your kernel and install the kernel and selected modules, issue the following command.  I find that this one works a bit better than some of the other one-liner kernel compilation commands.  If you should run into a problem where kernel compilation fails, its easy to determine where the problem was.  In addition, this command will also install the kernel for you:

```
# make && make modules && make modules_install && make install  
```

10.  Configuring the System

10.1  Configure Network Adapters

Configure your network adapters as recommended in the Gentoo Installation Handbook.  In our case, we'll use DHCP:

```
# cat /etc/conf.d/net

iface_eth0="dhcp"

dhcpcd_eth0="-t 10" 

```

If this isn't suitable for you, consider these options as listed in the GIH:

```
# (For DHCP)

iface_eth0="dhcp"

# Some network admins require that you use the

# hostname and domainname provided by the DHCP server.

# In that case, add the following to let dhcpcd use them.

# That will override your own hostname and domainname definitions.

dhcpcd_eth0="-HD"

# If you intend on using NTP to keep your machine clock synchronized, use

# the -N option to prevent dhcpcd from overwriting your /etc/ntp.conf file

dhcpcd_eth0="-N"

#(For static IP)

iface_eth0="192.168.0.2 broadcast 192.168.0.255 netmask 255.255.255.0"

gateway="eth0/192.168.0.1"

#(For rp-pppoe)

iface_eth0="up"

```

10.2  Set Hostnames and Domainnames

The following hostname and domainname locations referenced in the Gentoo Installation Handbook and some of the other HowTo appear to have been deprecated. The first example in each of the following two sections uses the old configuration method, which has been deprecated but this is not yet reflected in many of the installation guides.  The second option in each of the following two examples is more current:

10.2.1  Set Your Hostname 

The following examples provide instruction for setting the hostname on your Gentoo box.  Since we're installing Gentoo on an old Pentium-class PC, we'll use the "boatanchor" as the hostname in this example. 

```
# echo boatanchor > /etc/hostname 
```

or

```
# cat /etc/conf.d/hostname

HOSTNAME="boatanchor"

```

10.2.2  Set Your Domainname  

```
# echo mydomain.com > /etc/dnsdomainname 

# echo nis.mydomain.com > /etc/nisdomainname 
```

or

```
# cat /etc/conf.d/domainname

OVERRIDE=1

DNSDOMAIN="mydomain.com"

NISDOMAIN="nis.mydomain.com"

```

10.2.3  Update /etc/hosts

If nameservers on your network handle all name resolution, then you can skip this step.

If your PC is a standalone system, or if your PC has a static IP address and you don't have DNS entries for your machine in a nameserver somwehere on your network, then you should specify the following information in the /etc/hosts file.  

```
127.0.0.1             localhost.localdomain       localhost

static.ip.addr.ess    boatanchor.mydomain.com     boatanchor
```

The value of "static.ip.addr.ess" needs to be substituted with the IP address of your Gentoo box.  For example, if your Gentoo box's IP address is 192.168.0.5, your /etc/hosts file should contain the following lines.

```
127.0.0.1        localhost.localdomain       localhost

192.168.0.5      boatanchor.mydomain.com     boatanchor
```

10.2.4 Add domainname to the Default Runlevel

```
# rc-update add domainname default

```

10.3  Gensplash

For all of you eye-candy addicts who can't live without it, here's the section where we add gensplash to give us those ultra-cool  :Cool:  framebuffer images in our consoles.  Because some of us have really big monitors, we'll configure splash screens at your choice of 1024x768, 1280x1024 and 1600x1200 resolutions:

```
# emerge splashutils splash-themes-gentoo

# splash_geninitramfs -v -g /boot/fbsplash-emergence-1024x768 -r 1024x768 emergence && splash_geninitramfs -v -g /boot/fbsplash-emergence-1280x1024 -r 1280x1024 emergence && splash_geninitramfs -v -g /boot/fbsplash-emergence-1600x1200 -r 1600x1200 emergence && rc-update add splash default 
```

Note:  Gensplash and the framebuffer is UNSUPPORTED in the Stage 1/3 Guide.

10.4  Grub Bootloader

10.4.1  Grub.conf

To boot our installation of Gentoo Linux we'll need to configure a boot menu for the Grub Bootloader.  Use your favorite text editor to create the /boot/grub/grub.conf file.  In this case we'll use nano:

```
# cd /boot/grub

# nano -w grub.conf
```

You can either cut and paste the following text into the file, or type it in manually.  Note that the lines beginning with the word "kernel" and ending with the words "splash=verbose,theme:emergence" need to be typed on one line.  In this example, we're using the vesafb-tng video driver, and the video= statements are formatted accordingly.

```
# Grub boot menu configuration file 

# 

# Boot automatically after 30 secs. 

timeout 30 

# By default, boot the second entry. 

default 1 

# Fallback to the first entry. 

fallback 0 

# Use default Grub Splash image

# splashimage=(hd0,0)/grub/splash.xpm.gz

#

# Use custom (downloaded) Gentoo Splash Image

splashimage=(hd0,0)/grub/gentoo.xpm.gz 

# Boot Gentoo Linux (no framebuffer)

title Gentoo-2.6.12-r6  

root (hd0,0) 

kernel (hd0,0)/vmlinuz ro root=/dev/hda3 video=vesafb:ywrap,pmipal,1024x768-16@85

# Boot Gentoo Linux at 1024x768 framebuffer resolution

title Gentoo-2.6.12-r6, 1024x768 

root (hd0,0) 

kernel (hd0,0)/vmlinuz ro root=/dev/hda3 video=vesafb:ywrap,pmipal,1024x768-24@85 splash=verbose,fadein,theme:emergence CONSOLE=/dev/tty1

initrd (hd0,0)/fbsplash-emergence-1024x768 

# Boot Gentoo Linux at 1280x1024 framebuffer resolution

title Gentoo-2.6.12-r6, 1280x1024 

root (hd0,0) 

kernel (hd0,0)/vmlinuz ro root=/dev/hda3 video=vesafb:ywrap,pmipal,1280x1024-24@85 splash=verbose,fadein,theme:emergence CONSOLE=/dev/tty1

initrd (hd0,0)/fbsplash-emergence-1280x1024 

# For installing GRUB into the hard disk 

title Install GRUB into the hard disk 

root (hd0,0) 

setup (hd0) 

```

10.4.2  Installing Grub onto the Hard Disk

Start Grub from the command prompt and use the following commands to embed grub into the hard disk. Remember, when counting hard disks we like to start at 1, but Grub likes to start at 0, so /dev/hda1 corresponds to hard disk 0, partition 0 in Grub.

```
# grub 

grub> root (hd0,0) 

grub> setup (hd0) 

grub> quit 

```

10.4.3  Download a Cool  :Cool:  Grub Splash Screen

We'll also download a cool Gentoo-specific splash screen for Grub.

```
wget http://www.schultz-net.dk/downloads/grub/gentoo.xpm.gz
```

10.5  Filesystem - Configuring fstab

This is a sample /etc/fstab file that reflects the disk partition scheme used earlier in this Installation Guide.  Make changes as appropriate if your partition scheme is different.

```
# <fs>               <mountpoint>  <type>       <opts>               <dump/pass> 

/dev/hda1            /boot         reiserfs     noauto,notail        1 2 

/dev/hda3            /             reiserfs     notail               0 1 

/dev/hda2            none          swap         sw                   0 0 

/dev/cdroms/cdrom0   /mnt/cdrom    iso9660      user,noauto,ro,exec  0 0 

/dev/fd0             /mnt/floppy   auto         noauto,users         0 0 

# NOTE: The next line is critical for boot! 

none                 /proc         proc         defaults             0 0 

# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for 

# POSIX shared memory (shm_open, shm_unlink). 

# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will 

# use almost no memory if not populated with files) 

# Adding the following line to /etc/fstab should take care of this: 

none                 /dev/shm      tmpfs        nodev,nosuid         0 0

```

10.6  Setting HD Paramaters

Back in Section 4 we developed optimized operating parameters for our hard disk.  Now that we're in the chrooted environment of our newly designed Gentoo system, we need to make these configuration changes permanent.  To do this, we'll write the HD parameters to the /etc/conf.d/hdparm file:

```
# cat /etc/conf.d/hdparm 

disc0_args="-a256A1c1d1m16u1" 

cdrom0_args="-d1c1u1" 

```

After editing the contents of /etc/conf.d/hdparm type the following command to add hdparm to the boot runlevel. 

```
# rc-update add hdparm boot 
```

10.7  Set-Up User Accounts

We must change the password of the root user in our newly installed system.  Then we will add non-root users to the system.  Substitute the username examples "bob" and "mary" with your own usernames.

First, change the root password:

```
# passwd

New password: (Enter your new password)

Re-enter password: (Re-enter your password) 
```

Now add users who will be allowed to "su" their way to temporary root status.  These users must be added to the "wheel" user group:

```
# useradd -m -G users,wheel bob 

# passwd bob

New password: (Enter bob's password)

Re-enter password: (Re-enter bob's password) 
```

Now add non-root users to the system:

```
# useradd -m -G users mary 

# passwd mary

New password: (Enter mary's password)

Re-enter password: (Re-enter mary's password) 
```

10.8  Toggle NUMLOCK ON at Boot

If you'd like the NUMLOCK key to be toggled ON at system boot, execute the following command.

```
# rc-update add numlock default
```

10.9  Define Console Screen Blanking Interval

If youre not happy with the standard screen blanking interval for the console (to me the screen always seems to blank too quickly), you can specify the desired interval (from 1 to 60 minutes) using the following command.  Substitute n with the value of the desired blanking interval in minutes.  A value of zero will disable screen blanking.

```
# setterm -blank n
```

This setting is only temporary; after rebooting the screen will resume blanking at the default interval.  To make your changes permanent, issue the following command:

```
# echo setterm blank n >> /etc/conf.d/local.start
```

10.10  Exiting Chroot and Unmounting Partitions 

We will now exit the chrooted environment and unmount all of the mounted partitions. 

```
exit 

cd ~/ 

umount /mnt/gentoo/proc /mnt/gentoo/boot /mnt/gentoo 

swapoff /dev/hda2

```

11.  REBOOT!

And now, the moment you've been waiting for!

```
# shutdown -r now 
```

When the system reboots, you should be welcomed with the following greeting.

```
This is boatanchor.mydomain.com (Linux i586 2.6.10-gentoo-r2) HH:MM:SS

boatanchor login:
```

12.  TROUBLESHOOTING

If you encounter problems after rebooting, consider the following:

 :Arrow:  kernel configuration errors are the most common cause of failure on first boot.

 :Arrow:  grub configuration errors are another common cause of failure on first boot.

 :Arrow:   if you have device problems, read the Gentoo udev Guide.

Have fun with your new Gentoo system!

13.  If You Need Help

Remember: The Documentation, Tips & Tricks forum is not a support forum:

 *Quote:*   

> Documentation, Tips & Tricks
> 
> Unofficial documentation for various parts of Gentoo Linux. Note: This is not a support forum.
> 
> Moderator: Global Moderators

 

Please bear in mind that this thread is located in the Documentation, Tips & Tricks Forum, which is not a support forum.  For this reason I would like to ask that we limit the context of this thread to posts that discuss problems with the Installation Guide that need to be corrected, or to ideas about how to improve the Stage 1 on 3 installation procedure itself.  If you have a problem and you need help, please post your support request in the Official 2005.0 Stage 1 on 3 for GCC 3.4.4 Support Thread in the Installing Gentoo forum.

NOTE: Documentation, Tips & Tricks  is NOT a support forum.  Please do not post installation support requests into this thread.  Please post in the support thread that is dedicated to this installation method.

14.  Another Essential Tool: Emerge Wrapper for System Updates

This installation guide is focused on how to install Gentoo, and it specifically avoids the issue of how to maintain your Gentoo installation.  Hielvc and MindEraser have developed a fabulous emerge wrapper for system updates that his highly recommended.  Check out the following thread:  An emerge wrapper for correctly building the toolchain.

15.  Corrections, Errors, Omissions 

Please let me know if there are any errors or omissions in this document by sending me a personal message through the Gentoo Forums by clicking the link below.

16.  Downloadable PDF Now Available

A PDF version of this Guide is now available.   Click Here.

Please note that this document is presently in a state of transition, and that revisions may be required if errors are found in the document.  

17. Support my Documentation Writing Efforts

If this Guide has helped you and you'd like to show your appreciation, feel free to visit my Stage 1/3 Web Page.

18. REVISION HISTORY

2005-06-05:  corrected typos.

2005-06-15:  added hyperlink to Support Thread.

2005-08-14:  updated Introduction to clarify the resolution of the /var/db/pkg issue in 2005.0.

2005-08-15:  updated for Gentoo-Sources 2.6.12 idiosyncracies and new grub.conf kernel commands

2005-08-22:  updated gcc-config 6

2005-11-05:   updated package.keywords to reflect nightmorph's old recommendations re: glibc-2.3.5-r3 and timezone-data.

Google Sucks.

The Jackass! Project website at http://jackass.homelinux.org had been participating in the Google AdSense program since I took over the webserver's hosting duties in May, 2005.  We've been hosting Ads by Google at The Jackass! Project for 4 months now, in the hope that Ads by Google would help to offset some of the expenses involved in hosting the web site.

Click-through revenues have always been low -- over the four months that we've been participating in Ads by Google, we had never generated enough revenue to generate a payout check from Google.  That looked like it would all change on Friday, as on Friday we crossed threshold -- we had finally generated the $100 minimum balance to qualify for disbursement in the form of a check.  According to the program standards, Google was supposed to send us a check sometime next month.

The illusion of actually being paid what we were owed by Google ended today -- two days after our successfully became elegible for payment, I received an e-mail that vaguely accused The Jackass! Project of some form of illegitimate robotic clicking activity, but failed to identify the nature of the problem.  In the email, we were told that our account had been canceled and that our $100 would be kept by Google instead of being paid to us under the terms of our participation agreement.

We participated in good faith in the Ads by Google program for four months.  Our users supported the project by clicking on the ads.  Now that its time for Google to actually pay what they owe us, they unilaterally decided to close our account.  They kept our money.   They even deleted our account records so that we don't have sufficient documentation to file a letter of protest.

The moral of the story:  don't waste your time with Ads by Google.  They don't honor their debts.

The saddest part of this is that we've lost a source of revenue that we were counting on to support the Jackass! Project.  Now we'll have to find an alternative method of offseting our operating expenses.

----------

## amne

Moved from Installing Gentoo to Documentation, Tips & Tricks. I assume in here is a better place for this.

----------

## Bob P

i'm okay with that if that's the way you'd like it.  i had thought that since this was an experimental method, it should be posted elsewhere, as the Guides that get posted in the Documentation Tips & Tricks forum are expected to work!   :Razz: 

----------

## Ansur

I was about to install Gentoo on my laptop so I'll follow this guide, hopefully everything works out fine  :Wink: 

----------

## Bob P

I just updated a perfectly functional GCC 3.4.3 system to GCC 3.4.4 and ran into the following problem immediately after emerging gcc:

```
# gcc-config -l

/usr/bin/gcc-config: line 1: /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110: No such file or directory

 * /usr/bin/gcc-config: Profile does not exist or invalid setting for /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110

[1] i686-pc-linux-gnu-3.4.4

[2] i686-pc-linux-gnu-3.4.4-hardened

[3] i686-pc-linux-gnu-3.4.4-hardenednopie

[4] i686-pc-linux-gnu-3.4.4-hardenednopiessp

[5] i686-pc-linux-gnu-3.4.4-hardenednossp

```

so i tried specifying the first option, and here's what happened:

```
gentoo pentium # gcc-config 1

 * Switching to i686-pc-linux-gnu-3.4.4 compiler...

/usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

 * /usr/bin/gcc-config: Could not get portage CHOST!

/usr/bin/gcc-config: line 1: env: command not found

 * /usr/bin/gcc-config: Could not get portage CHOST!

/usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

 * /usr/bin/gcc-config: Could not get portage CHOST!

/usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

 * /usr/bin/gcc-config: Could not get portage CHOST!

/usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

 * /usr/bin/gcc-config: Could not get portage CHOST!                                                                                                  [ ok ]

 * If you intend to use the gcc from the new profile in an already

 * running shell, please remember to do:

 *   # source /etc/profile

```

interestingly, the libstdc++.so.6 file is indeed available as a symlink to libstdc++.so.6.0.3:

```
gentoo pentium # ls -lh /usr/lib/gcc/i686-pc-linux-gnu/3.4.4

total 5.3M

-rw-r--r--  1 root root 1.7K Jun  4 14:03 crtbegin.o

-rw-r--r--  1 root root 2.2K Jun  4 14:03 crtbeginS.o

-rw-r--r--  1 root root 2.0K Jun  4 14:03 crtbeginT.o

-rw-r--r--  1 root root 1.3K Jun  4 14:03 crtend.o

-rw-r--r--  1 root root 1.5K Jun  4 14:03 crtendS.o

-rw-r--r--  1 root root 4.5K Jun  4 14:03 hardened.specs

-rw-r--r--  1 root root 4.5K Jun  4 14:03 hardenednopie.specs

-rw-r--r--  1 root root 4.5K Jun  4 14:03 hardenednopiessp.specs

-rw-r--r--  1 root root 4.5K Jun  4 14:03 hardenednossp.specs

drwxr-xr-x  4 root root  536 Jun  4 14:03 include

drwxr-xr-x  3 root root  136 Jun  4 14:03 install-tools

-rw-r--r--  1 root root 1.2K Jun  4 14:03 libfrtbegin.a

-rw-r--r--  1 root root 349K Jun  4 14:03 libg2c.a

-rwxr-xr-x  1 root root  754 Jun  4 14:03 libg2c.la

lrwxrwxrwx  1 root root   15 Jun  4 14:03 libg2c.so -> libg2c.so.0.0.0

lrwxrwxrwx  1 root root   15 Jun  4 14:03 libg2c.so.0 -> libg2c.so.0.0.0

-rwxr-xr-x  1 root root 160K Jun  4 14:03 libg2c.so.0.0.0

-rw-r--r--  1 root root 259K Jun  4 14:03 libgcc.a

-rw-r--r--  1 root root  94K Jun  4 14:03 libgcc_eh.a

lrwxrwxrwx  1 root root   13 Jun  4 14:03 libgcc_s.so -> libgcc_s.so.1

-rw-r--r--  1 root root  35K Jun  4 14:03 libgcc_s.so.1

-rw-r--r--  1 root root  37K Jun  4 14:03 libgcov.a

-rw-r--r--  1 root root 1.7M Jun  4 14:03 libstdc++.a

-rwxr-xr-x  1 root root  909 Jun  4 14:03 libstdc++.la

lrwxrwxrwx  1 root root   18 Jun  4 14:03 libstdc++.so -> libstdc++.so.6.0.3

lrwxrwxrwx  1 root root   18 Jun  4 14:03 libstdc++.so.6 -> libstdc++.so.6.0.3

-rwxr-xr-x  1 root root 812K Jun  4 14:03 libstdc++.so.6.0.3

-rw-r--r--  1 root root 1.8M Jun  4 14:03 libstdc++_pic.a

-rw-r--r--  1 root root 149K Jun  4 14:03 libsupc++.a

-rwxr-xr-x  1 root root  849 Jun  4 14:03 libsupc++.la

-rw-r--r--  1 root root 4.5K Jun  4 14:03 specs

-rw-r--r--  1 root root 4.5K Jun  4 14:03 vanilla.specs

```

in my case, the problem seems to be related to the fact that  /etc/ld.so.conf is not being properly updated.  so i changed this:

```
# cat /etc/ld.so.conf

# ld.so.conf autogenerated by env-update; make all changes to

# contents of /etc/env.d directory

/usr/local/lib

/usr/lib/opengl/xorg-x11/lib

/usr/i686-pc-linux-gnu/lib

/usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110

/usr/lib/MozillaFirefox

/usr/lib

/usr/qt/3/lib

/usr/kde/3.3/lib

/usr/lib/libstdc++-v3/
```

to this:

```
gentoo pentium # cat /etc/ld.so.conf

# ld.so.conf autogenerated by env-update; make all changes to

# contents of /etc/env.d directory

/usr/local/lib

/usr/lib/opengl/xorg-x11/lib

/usr/i686-pc-linux-gnu/lib

#/usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110

/usr/lib/gcc/i686-pc-linux-gnu/3.4.4

/usr/lib/MozillaFirefox

/usr/lib

/usr/qt/3/lib

/usr/kde/3.3/lib

/usr/lib/libstdc++-v3/

```

then i ran ldconfig -v which appeasr to have solved the problem.   :Wink: 

i honestly don't know if you'll run into these problems when performing the Stage 1/3 Install with GCC 3.4.4, but i've posted it for your guys just in case...

----------

## Bob P

GCC 3.4.4 install failure related to libstdc++.so.6 reported to bugzilla:  https://bugs.gentoo.org/show_bug.cgi?id=95062

----------

## rutski89

```
# cat /etc/portage/package.keywords

~sys-devel/gcc-3.4.4 ~x86

sys-devel/gcc-config ~x86

sys-libs/libstdc++-v3 ~x86

sys-libs/glibc ~x86
```

 ~sys-devel/gcc-3.4.4 ~x86 Are you sure thats right? A '~' in the front with a version number attached? I've persoanlly never seen either, what do they do?

----------

## Bob P

 *rutski89 wrote:*   

> 
> 
> ```
> # cat /etc/portage/package.keywords
> 
> ...

 

hehe.  yes, i'm sure that's right.   :Wink:     just because you've never seen somebody use a valid package masking atom with a version number doesn't mean that its invalid!   :Embarassed: 

the atom specifically enables the testing branch version of GCC while restricting the testing branch version number to 3.4.4.  it may be helpful to review the rules on atoms that are used for package masking if the syntax of the command seems unfamiliar.  :Idea: 

----------

## rutski89

Great, that makes sense  :Very Happy:  It un-maskes 3.4.4 and 3.4.4 only. Where are these atom rules? I remeber a while back seeing some basic stuff in the "how to work with portage" documentation, but they were never this detalied. Also, I under stand what it does, however, isn't specifing the version number enough for this? What does the '~' mean  :Embarassed:  ? Feel Free to put a link to an faq/doc as your answer if you know one  :Shocked: 

----------

## 96140

the ~ in front of the package means that any revision of gcc 3.4.4 can be used; whenever the ebuild for gcc 3.4.4-r1, or 3.4.4.20050610-r3, or 3.4.4-r78 comes out, gcc 3.4.4 will be upgraded to this latest version. It still locks in the base package series of gcc 3.4.4, while allowing any suffixes to be added to this. So 3.4.4.20050610 is allowed, but NOT 3.4.5, for example.

----------

## rutski89

 *nightmorph wrote:*   

> the ~ in front of the package means that any revision of gcc 3.4.4 can be used; whenever the ebuild for gcc 3.4.4-r1, or 3.4.4.20050610-r3, or 3.4.4-r78 comes out, gcc 3.4.4 will be upgraded to this latest version. It still locks in the base package series of gcc 3.4.4, while allowing any suffixes to be added to this. So 3.4.4.20050610 is allowed, but NOT 3.4.5, for example.

 Wonderful, thats exactly the answer I was looking for. I'm sure the BoB P didn't answer because its busy testing this guide  :Cool: 

----------

## Clyde

I think sections 7.2.5 and 7.2.6 are accidentally reversed. Also, the 7.2.5 summary one-liners are missing the libstdc++-v3 from sections 7.1 and 7.2.4.

----------

## Ansur

A general question: *Quote:*   

> This Guide uses a minimalist setting of the USE variable. You are free to add additional USE flags as needed for your specific system requirements, but it is recommended that you do not add them to /etc/make.conf until after you have completed the entire installation. 

 

Would that mean that when the installation is finished, you add the use-flags you want and start compiling whatever you want, or should you then perform 

```
emerge -e system
```

 again?

----------

## Naveg

does this guide fix the dreaded libstdc++ errors?

----------

## Ansur

There were no problems here, at least, though this is only a single case  :Smile: 

----------

## Bob P

 *nightmorph wrote:*   

> the ~ in front of the package means that any revision of gcc 3.4.4 can be used; whenever the ebuild for gcc 3.4.4-r1, or 3.4.4.20050610-r3, or 3.4.4-r78 comes out, gcc 3.4.4 will be upgraded to this latest version. It still locks in the base package series of gcc 3.4.4, while allowing any suffixes to be added to this. So 3.4.4.20050610 is allowed, but NOT 3.4.5, for example.

 

actually, its a bit more complicated than that.  i thought that it worked that way, but when we were building Jackass! we found that portage is kind of fussy when it comes to names like 3.4.3 vs. 3.4.3.20050125.  with the tilde atom in the front of the statement, portage will use all subsequent versions that are direct wildcard descendants of what is written.  

for example, with the tilde atom enabled for GCC 3.4.3, portage will use the -r1 and -2 versons of GCC 3.4.3.  

in contrast. with the tilde atom enabled for GCC 3.4.3, portage will NOT use GCC 3.4.3.20050125, even though portage's atom rules suggest that it should.   :Sad: 

----------

## Bob P

 *Clyde wrote:*   

> I think sections 7.2.5 and 7.2.6 are accidentally reversed. Also, the 7.2.5 summary one-liners are missing the libstdc++-v3 from sections 7.1 and 7.2.4.

 

the layout of sections 7.2.5 and 7.2.6 was actually right.  the summary steps that were listed in Section 7.2.5 (all of the way up to emerge -e system) really do have to be performed BEFORE gcc is pruned in Section 7.2.6.  

i've added the libstdc++-v3 steps to the Summary.

nobody seems to have noticed that the pruning of GCC was in the wrong place in Step 3 of the Summary -- i had left it where it was from the 3.4.3 version of the guide, but now i've changed that.   as a result, the summary has been revised to include pruning as the last step, and the last 2 sections of 7.2.x have been rewritten and the numbering scheme has been changed so that the summary is now the last step in the section.  this should make things easier for less experienced users to follow.  

thanks for the feedback.

----------

## Bob P

 *Ansur wrote:*   

> A general question: *Quote:*   This Guide uses a minimalist setting of the USE variable. You are free to add additional USE flags as needed for your specific system requirements, but it is recommended that you do not add them to /etc/make.conf until after you have completed the entire installation.  
> 
> Would that mean that when the installation is finished, you add the use-flags you want and start compiling whatever you want, or should you then perform 
> 
> ```
> ...

 

yes to the first part, no to the second part.  

 :Arrow:  Gentoo Fundamental: if there's a question about whether you need to perform a recompile after updating your USE flags, then do an emerge --newuse --pretend.  :Idea: 

----------

## Bob P

 :Arrow:  Official Support Thread for 2005.0 & GCC 3.4.4 -- click here.

----------

## Clyde

 *Bob P wrote:*   

>  *nightmorph wrote:*   the ~ in front of the package means that any revision of gcc 3.4.4 can be used; whenever the ebuild for gcc 3.4.4-r1, or 3.4.4.20050610-r3, or 3.4.4-r78 comes out, gcc 3.4.4 will be upgraded to this latest version. It still locks in the base package series of gcc 3.4.4, while allowing any suffixes to be added to this. So 3.4.4.20050610 is allowed, but NOT 3.4.5, for example. 
> 
> actually, its a bit more complicated than that.  i thought that it worked that way, but when we were building Jackass! we found that portage is kind of fussy when it comes to names like 3.4.3 vs. 3.4.3.20050125.  with the tilde atom in the front of the statement, portage will use all subsequent versions that are direct wildcard descendants of what is written.  
> 
> for example, with the tilde atom enabled for GCC 3.4.3, portage will use the -r1 and -2 versons of GCC 3.4.3.  
> ...

 

Perhaps 3.4.3.20050125 is considered a version and not a revision, since it has no "-r". In other words, it's a subversion.  :Wink: 

If the goal is to use testing branch toolchain components, but prevent accidental toolchain updates, would it make sense to use = instead of ~ ?

----------

## mudrii

-fomit-frame-pointer is default in gcc 3.4.4 and do not need to insert in make.conf

From GCC manual 3.4.4

```
-fomit-frame-pointer

    Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.

    On some machines, such as the VAX, this flag has no effect, because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it doesn't exist. The machine-description macro FRAME_POINTER_REQUIRED controls whether a target machine supports this flag. See Register Usage.

    Enabled at levels -O, -O2, -O3, -Os. 
```

----------

## Bob P

 *mudrii wrote:*   

> -fomit-frame-pointer is default in gcc 3.4.4 and do not need to insert in make.conf
> 
> From GCC manual 3.4.4

 

the subject of CFLAGS redundancy has been beaten to death in the other threads that led up to this one.   you have mentioned this before, so the response will be the same this time as it was the last time that you asked it:  we are doing it on purpose.  

personally, i don't see much point in beating a dead horse (unless you're just trolling).  if you don't want to specify the flag redundantly on your system, you don't have to, but please accept that there is a good reason for why we are doing what we are doing, and that the flag specification is intentional and is not an error.   :Wink: 

Edit:  yes, the same question has already been asked and answered: https://forums.gentoo.org/viewtopic-t-319349-start-84.html

----------

## Bob P

 *Clyde wrote:*   

> Perhaps 3.4.3.20050125 is considered a version and not a revision, since it has no "-r". In other words, it's a subversion.  

 

well, depending upon you look at it, this issue is either caused by a defect in Portage not behaving the way that the documentation says its supposed to behave, or by a defect in the documentation not fully explaining how Portage deals with sub-versions.  either way, the documentation does not fully explain the application's behavior, and i've had to observe the applications's behavior to determine how it actually behaves.  sure, I've been able to figure out Portage's idiosyncracies and exploit them to our advantage, but this doesn't change the fact that the docs don't accurately reflect the application's behavior and need to be updated.  

 *Quote:*   

> If the goal is to use testing branch toolchain components, but prevent accidental toolchain updates, would it make sense to use = instead of ~ ?

 

the goal of the package masking in the Guide is actually to specify what toolchain components are emerged when rebuilding the system, not to control user behavior at some later point in time.  updating the system is ultimately the user's responsibility, and you and i have already discussed that in depth on page 8 of the Jackass! Support Group, so I don't see a need to rehash it over again.  ultimately, the user is responsible for updates that he performs on his system, and i've recommended hielvc's scripts for that purpose.

i'm going to avoid the opportunity to take this thread off on a tangent that discusses the pros and cons of various package masking strategies.  if the masking method that i've used in the Guide doesn't suit your needs, you're free to change it.  the problem is that making subtle changes to the syntax of the masking atoms can wreak havoc on the system if you should make even a trivial mistake.  as a result, i recommend one and only one masking specification, and i offer no support for people who choose to deviate from it.  if my recommendation doesn't suit you, you're free to experiment with alternative methods -- just don't ask for support if you don't follow the Guide and something breaks as a result.  if you choose to modify the specification files, then you're on your own.

----------

## DrDoverylittle

 *Bob P wrote:*   

>  *Clyde wrote:*   I think sections 7.2.5 and 7.2.6 are accidentally reversed. Also, the 7.2.5 summary one-liners are missing the libstdc++-v3 from sections 7.1 and 7.2.4. 
> 
> the layout of sections 7.2.5 and 7.2.6 was actually right.  the summary steps that were listed in Section 7.2.5 (all of the way up to emerge -e system) really do have to be performed BEFORE gcc is pruned in Section 7.2.6.  
> 
> i've added the libstdc++-v3 steps to the Summary.
> ...

 

Well i must be a real Jackass, cause i tried to do a Stage 1/3 gcc 3.4.4 over the weekend and only got a chance to see this thread today when i was back at work.

I based my method on your 3.4.3 version, and did not have any problems with pruning gcc right after the first build of gcc 3.4.4 with the 3.3.5 version.

What problems was this meant to cause, why are you not meant to prune gcc 3.3.5 til after emerge -e system if you are no longer compiling anything else with 3.3.5 ?

----------

## Bob P

if you didn't have a problem, that may be a result of the ebuild having been fixed during Saturday's bug day.  :Wink: 

the reason for moving the prune step after emerge -e system is rather complex.  the python ebuilds are notorious for buggy programming in which static libary references to old versions of GCC are maintained.   in the event that python is retaining static library references to GCC 3.3.5, they may not be purged from the system until two emerge -e worlds are performed.  if that's the case, then pruning the GCC compiler and removing GCC 3.3.5 will remove the libaries that python is trying to find, and compilation will halt with a fatal error.  by removing the pruning step, the incorrect libraries are maintained on the system so that python will not fail.  hopefully two emerge -e systems will purge them, and the pruning step can safely be performed thereafter.

unfortunately, if the ebuilds were written proplerly, then no modification of the Stage 1/3 Guide for GCC 3.4.3 would have been necessary.  The GCC 3.4.4 version of this Guide was written as a kludge workaround for deficiencies in some of the ebuilds.

this is a pretty good example of why the Stage 1/3 Installation Method is only recommended for experts.

----------

## netjunkie

Hi,

after following this guild everything works until step 7.2.4

```
 # emerge glibc binutils libstdc++-v3 gcc portage
```

it crashes on compile step 1, during the recompiling of glibc with the following error

---------

make[2]: *** [/var/tmp/portage/glibc-2.3.5/work/build-default-i586-pc-linux-gnu-linuxthreads/linuxthreads/libpthread.so] Error 1

make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.5/work/glibc-2.3.5/linuxthreads'

make[1]: *** [linuxthreads/others] Error 2

make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.5/work/glibc-2.3.5'

make: *** [all] Error 2

!!! ERROR: sys-libs/glibc-2.3.5 failed.

!!! Function toolchain-glibc_src_compile, Line 237, Exitcode 2

!!! (no error message)

!!! If you need support, post the topmost build error, NOT this status message.

------------

any ideas

----------

## Bob P

No answers to support questions will be posted here.  You need to use the Support Thread.   :Idea: 

----------

## spidna

quick question on Bob P installation guide, after the installation do i have to emerge  sync, emerge -u world, emerge xorg. i'm going to try that today night when i get home with a friends computer. going install windows xp , gentoo and centos. centos on /dev/hdb while other operating system would be on /dev/hda.  I guess i'm going to use grub from centos, would not have to install  grub on gentoo but fix the /etc/fstab. using ext3 filesystem.

----------

## Naveg

well....technically you dont HAVE to emerge xorg-X11.....but i think most people do  :Wink: 

----------

## Iron_DragonLord

This is not really a support question but one about the installation method.

Are hotplug and coldplug really needed? My friend is using udev without them, and I just switched my server to udev and I did not emerge hotplug and coldplug, it seems to be working fine.

----------

## Iron_DragonLord

Nevermind, I answered my own question:

http://www.gentoo.org/doc/en/udev-guide.xml#doc_chap2

 *Quote:*   

> You do not need to install hotplug unless you want your modules automatically loaded when you plug devices in. hotplug also handles the automated bringup of network devices and firmware downloading.
> 
> ...
> 
> If you want modules loaded for devices that have been plugged in before you boot, use the coldplug package:

 

Apparently then, hotplug and coldplug are optional, depending on your needs. Maybe this should be noted in the guides for other people? Although, generally, I suppose most people will want it.

----------

## Bob P

 :Arrow:  Problems Setting Hostname & Domainname

the new stable branch versions of baselayout have deprecated the use of /etc/hostname and /etc/dnsdomainname in favor of /etc/conf.d/hostname and /etc/conf.d/domainname.  if you install/update to sys-apps/baselayout-1.11.12-r4 or later and you've used the deprecated /etc/hostname and /etc/dnsdomainname methods, you'll notice boot warnings.  you can make them go away by following the second set of examples in Section 10.2 of the Stage 1/3 Guide.

----------

## slaterson

i have been going through this howto today and ran into the following error when doing an 'emerge -e system'.  the error occurs on package dev-python/python-fchksum-1.7.1 (18 of 90 for emerge -e system).

```
running build

running build_ext

building 'fchksum' extension

creating build

creating build/temp.linux-i686-2.3

i386-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -O3 -march=pentium -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe -fPIC -I/usr/include/python2.3 -c md5.c -o build/temp.linux-i686-2.3/md5.o

gcc-config error: Could not run/locate "i386-pc-linux-gnu-gcc"

error: command 'i386-pc-linux-gnu-gcc' failed with exit status 1

!!! ERROR: dev-python/python-fchksum-1.7.1 failed.

!!! Function src_compile, Line 20, Exitcode 1

!!! (no error message)

!!! If you need support, post the topmost build error, NOT this status message.
```

i've searched the forums but came up empty handed (maybe my search skills are lacking, though).

any clues?  did i miss/screw up something along the way?

i386-pc-linux-gnu-gcc does exist in /usr/bin

thanks,

slate

----------

## j-m

 *slaterson wrote:*   

> 
> 
> i've searched the forums but came up empty handed (maybe my search skills are lacking, though).
> 
> any clues?  did i miss/screw up something along the way?
> ...

 

Try

```

gcc-config 1 && source /etc/profile && unset CHOST && emerge --resume -e system

```

----------

## slaterson

 *j-m wrote:*   

> Try
> 
> ```
> gcc-config 1 && source /etc/profile && unset CHOST && emerge --resume -e system
> ```
> ...

 

The --resume option emerges nothing.

If I unset CHOST, won't that build for an older architecture?  If thats true, how will it affect performance of my machine?

Thanks,

slate

----------

## rutski89

 *Bob P wrote:*   

> 7.2.6 Summary 
> 
> Although these command have been broken down into separate steps for the purpose of clarity, they can be concatenated into three steps. The one-liners in Steps 1 and 3 will take quite some time to complete, and represent good opportunities for you to take an extended break while Gentoo does its thing. 
> 
> Step 1:Code: 
> ...

 Whey do you have us run step 1, THEN add USE="nptl", then remerge? Would it make a difference if USE="nptl" was added before stelp 1?

----------

## Bob P

 *slaterson wrote:*   

> i have been going through this howto today and ran into the following error when doing an 'emerge -e system'.  the error occurs on package dev-python/python-fchksum-1.7.1 (18 of 90 for emerge -e system).
> 
> ```
> running build
> 
> ...

 

apparently you missed the notice not to post support requests here.  you're supposed to post them in the support thread.  just to drive the point home -- your question was answered long ago in the support thread.  reading it would be to your benefit.

----------

## Bob P

 *rutski89 wrote:*   

>  *Bob P wrote:*   7.2.6 Summary 
> 
> Although these command have been broken down into separate steps for the purpose of clarity, they can be concatenated into three steps. The one-liners in Steps 1 and 3 will take quite some time to complete, and represent good opportunities for you to take an extended break while Gentoo does its thing. 
> 
> Step 1:Code: 
> ...

 

CFLAGS and USE FLAGS are updated in Step 2 because they are not supported by the GCC 3.3.5 compiler.  you can't use them until you emerge GCC 3.4.3 or 3.4.4.  :Idea: 

----------

## zendal

changes for grub due to 2.6.12 kernel

and splashutils due to themes are no longer included must emerge the themes

----------

## Bob P

 *zendal wrote:*   

> changes for grub due to 2.6.12 kernel
> 
> and splashutils due to themes are no longer included must emerge the themes

 

your post isn't very clear.  would you care to elaborate?

----------

## 96140

I think he means that with the 2.6.12 kernel series and the newest stable splashutils, warnings pop up during their emerge that say to re-emerge splashutils after upgrading to that new kernel, which the newest splashutils requires. Also, the splash themes are no longer included in the splashutils package; they must be separately emerged with, for example, emerge media-gfx/splash-themes-gentoo. And finally, the new splash needs to be rebuilt by another geninitramfs command.

Oh, and there are now several *required* boot options that must be appended to the appropriate grub entries, including new formats for the previous options present in this Guide. I've been following the splash/kernel developments, and here are the related threads:

gentoo-sources-2.6.12 borks fbsplash

Kernel upgrade - bootsplash broken

boot error, vesafb/splashutils related

fbsplash problems with 2.6.12-gentoo-r4

----------

## zendal

I went back 

2.6.11 kernel

0.94 grub

and emerged the themes

There is also error in the package.keywords he typed

 *Quote:*   

> ~sys-devel/gcc-3.4.4 ~x86
> 
> sys-devel/gcc-config ~x86
> 
> sys-libs/libstdc++-v3 ~x86
> ...

 

Should be

```
sys-devel/gcc ~x86

sys-devel/gcc-config ~x86

sys-libs/libstdc++-v3 ~x86

sys-libs/glibc ~x86
```

For the package.mask if you want 2.6.11 and working grub

```
>sys-kernel/gentoo-sources-2.6.12

>sys-boot/grub-0.96
```

For the emergence them to be there

```
emerge splash-themes-gentoo
```

If you want more there is another theme file

```
emerge splash-themes-livecd
```

----------

## Bob P

 *zendal wrote:*   

> There is also error in the package.keywords he typed
> 
>  *Quote:*   ~sys-devel/gcc-3.4.4 ~x86
> 
> sys-devel/gcc-config ~x86
> ...

 

actually, the package keywords file is accurate as it exists in the Guide:  

```
~sys-devel/gcc-3.4.4 ~x86

sys-devel/gcc-config ~x86

sys-libs/libstdc++-v3 ~x86

sys-libs/glibc ~x86
```

this version of the Guide is specifically desgned to install GCC 3.4.4 and no other version of the GCC compiler.  the atom masking syntax used in the Guide's package.keywords file assures that only GCC 3.4.4 will be installed.  although the less specific syntax that you have recommended works right now (because GCC 3.4.4 is the latest unmasked testing branch ebuild in the portage tree) it undermines the specificity of the Guide's approach by allowing any more recent testing branch versions of GCC that are not masked to be installed in its place once they enter the portage tree.

suffice it to say that i've chosen to use the syntax that is used in the Guide because it will remain correct forever.  i chose to replace the syntax that i had previously used (the exact syntax that you had recommended) because it won't remain correct forever -- although it is right for now, eventually it will become wrong.

regarding the FB splash and kernel stuff:  i haven't taken the time to investigate the idiosyncracies of the 2.6.12 kernels as related to framebuffer splash and the bugs that have been inherent in its implementation.  i have had an open bug report on bugzilla about FB screenblanking errors that began with 2.6.9 kernels and have been persistent until now.  supposedly, Spock's newest additions to the 2.6.12 kernels have fixed the nagging problem that has been persistent from 2.6.9 through 2.6.11, and it appears that they require an upgrade of both gensplash and grub in addition to a kernel upgrade to fix the bug.  unfortunately, because 2.6.12 has been marked in the testing branch for most of its life, i haven't bothered to tinker with it.  i just don't have time for testing branch kernels anymore.  @nightmorph, thanks for those links that show all of the trouble i've been missing.   :Very Happy: 

thank you @zendal for posting the updates to the Guide relating to the new kernels, FB utils, and grub, and also for the contribution about masking for people who want to stay with the older kernels.

----------

## kueitao

Hello,

I have some questions about some steps in the guide that I don't understand.

(1) Why do we need to install libstdc++-v3? I know that when compiling gcc from sources, at least from version 3.4.0, the c++ library is automatically compiled at the same time. I've compiled lots of gcc-3.4.0 to gcc-4.0.0, with support for C,C++ and other languages, without ever undertaking any special actions with regard to libstdc++, except asking C++ support at configure. Is it perhaps because "emerge" doesn't work as a normal "configure && make (bootstrap) && make install" cicle?

(1.5) I have put parenthesys in "make bootstrap" because I want to know whether or not "emerge gcc" performs a real gcc bootstrap (three stages) or a simple make. How does it work? 

(2) In section 7.2.4 (Rebuilding the System Toolkit) there's the following instruction:

 # emerge -e system && emerge -e system

Why is it needed to repeat twice the same operation, seen that before that point we already have a new toolchain built with gcc-3.4.4? What am I missing?

----------

## 96140

1) IIRC, libstdc++ provides backward compatibility for the regular 3.3.x gcc series.

1.5) Emerging gcc is just that--compilation and installation of a package, not any special bootstrap per se.

2) This has been explained many times in the Stage 1/3 guides, the Jackass! Guide, and heilvc's correct toolchain thread. Please do look through those for detailed answers, but in short, recompiling the toolchain is necessary. Until that step, the only thing you have done is emerged a new toolchain and switched to that compiler. However, you have not yet begun using it; every package has been build with the wrong (read: OLD) gcc. Thus, now you have to recompile your packages in order to get immediate benefits of the new toolchain. If you do not recompile your system, then not only will it be somewhat unstable, but only future packages you emerge--like Gnome or AbiWord--will be built with the 3.4.4 toolchain. The rest of your system will still only be compiled from a 3.3.x toolchain, which is obviously undesirable.

Again, please search for the threads that I mentioned if you need further clarification; these questions come up over and over in those guides.

----------

## kueitao

 *nightmorph wrote:*   

> 1) IIRC, libstdc++ provides backward compatibility for the regular 3.3.x gcc series.

 

Why backward compatibility is needed? Don't we then re-compile all sources with 3.4.4? Don't we prune the gcc-3.3.5 compiler at section 7.2.5 (Prune the GCC Compiler) and then use only gcc-3.4.4 to "emerge -e system"?

Anyway I don't see any need to put re-compilation of an old libstdc++, even for compatibility (?!) reasons, in toolchain re-building, seen that it has got nothing to do with the workings of the new toolchain, it has nothing to do with newly compiled glibc and binutils too, so I think is plain wrong. (I would add that even name the toolchain as a "toolkit" is misbehaviour and potentially misconducting).

 *Quote:*   

> 1.5) Emerging gcc is just that--compilation and installation of a package, not any special bootstrap per se.

 

No, I'm sorry it's not true. I have now noticed that gcc is completely bootstapped, no simple "make". The command I see with "ps aux" is "make profiledbootstrap" (three stages + profile collection) that is a very different thing than "make".

 *Quote:*   

> 2) This has been explained many times in the Stage 1/3 guides, the Jackass! Guide, and heilvc's correct toolchain thread. Please do look through those for detailed answers, but in short, recompiling the toolchain is necessary. Until that step, the only thing you have done is emerged a new toolchain and switched to that compiler. However, you have not yet begun using it; every package has been build with the wrong (read: OLD) gcc. Thus, now you have to recompile your packages in order to get immediate benefits of the new toolchain. If you do not recompile your system, then not only will it be somewhat unstable, but only future packages you emerge--like Gnome or AbiWord--will be built with the 3.4.4 toolchain. The rest of your system will still only be compiled from a 3.3.x toolchain, which is obviously undesirable.

 

I am not speaking about the toolchain re-compilation, at all. What makes you to think that? At that point, that is at the end of section 7.2.4, we have already been said to rebuild the toolchain. So I am not speaking about the need to rebuild the toolchain, that is correct!

I am objecting about the need to do "emerge -e system && emerge -e system", that is after toolchain re-building with the new gcc-3.4.4. This means that we compile gcc, glibc e binutils FOUR times in total. Twice is correct, four times is again plain wrong and wasting of precious time.

What's more important is that there is no need I can imagine to "emerge system" twice, one after another as showed by "emerge system && emerge system". Whay do you think is it not enough to issue "emerge system", I mean only once? Every source at this point would be compiled by the new toolchain, the one that has already been rebuilt, and I think there would no difference in executables if you issue either a simple "emerge system" or "emerge system && emerge system && emerge system && ...". Doing it twice or more is plain wrong.

I have further noticed that in the other guide, Stage 1/3 Installation for Gentoo 2005.0 and GCC 3.4.3,  that in the same section (7.2.5) there aren't the same mistakes. Just one of them ("-e" option). Please take a look at that. There is only ONE "emerge -e system" after toolchain re-building.

So, why do you think there are these differences between the "Installation 1/3 with gcc-3.4.3" and "Installation 1/3 with gcc-3.4.4"?

 *Quote:*   

> Again, please search for the threads that I mentioned if you need further clarification; these questions come up over and over in those guides.

 

I'm sorry, but I am not able to find answers about the above-mentioned issues in this guide as you say they have been trated. Don't know what is the "Jackass" and how this topic is related to this guide.

Anyway I would like to hear on the above-mentioned issues from the guide's author too, if He is available to argue about his choices and explain them.

----------

## 96140

 *kueitao wrote:*   

> I am not speaking about the toolchain re-compilation, at all. What makes you to think that? At that point, that is at the end of section 7.2.4, we have already been said to rebuild the toolchain. So I am not speaking about the need to rebuild the toolchain, that is correct!

 

No, you are still incorrect. Please read step 7.2 carefully. Nowhere does it say that the toolchain has been rebuilt in 7.2.4--and yes, this is the gcc 3.4.3 guide, but the two are procedurally identical except for the particular gcc version used, that's all. The heading for the entire section is "rebuilding the toolchain" which is what will happen--NOT that it has been done by step 7.2.4. Prior to that step, the only thing that has been done is the new toolchain has been emerged. It has not yet begun to be rebuilt. Now that it is unmasked, it is installed. And then you need to start recompiling your system--which has still built only with 3.3.x to this point--in order to take advantage of it. Ignore any section title text that says "rebuilding" up through 7.2.4 and just look at the content of each step. Nowhere is there any recompiling, only the emergence of masked ~x86 toolchain packages. You really need to examine the procedure more carefully and not jump to conclusions.

The point of each successive emerge -e system is to verify that all the code is produced from gcc 3.4 and its supporting components. But this is not possible with only a simple emerge gcc binutils gcc-config glibc. See, since the new tools themselves were compiled with 3.3.x, they can only optimize the existing system code up to a certain point when you do the first emerge -e system. At that point they've rebuilt themselves but still only suboptimally. It takes the next few emerge -e system/world commands in order to remove any hint of the original 3.3.x compilation. Please read this thread to hear the more technical explanation of why this is necessary.

 *Quote:*   

> I'm sorry, but I am not able to find answers about the above-mentioned issues in this guide as you say they have been trated. Don't know what is the "Jackass" and how this topic is related to this guide.

 

See the link in my signature. Jackass! provides a canned version of this stage 1/3 install, but all the compiling has been done in advance. Same CFLAGS and NPTL advantages, but we took the trouble to compile everything ahead of time, so that your hardware is spared the abuse of recompiling. Really, though, if you don't think you have time to be recompiling or compiling at all, Gentoo might not be the best solution for your needs. Note that as Bob mentioned, anytime there is an update to one of the toolchain components, you will need to spend some time rebuilding your system, including a few emerge -e system commands, in order to reap the benefits of the new package.

----------

## Dark_Cloud

Sorry, but i still disagree with you... in 7.2.4 Rebuilding the System Toolkit the toolkit was totally rebuilt and at the final of that we had a working gcc-3.4.4 and all the packages (of course) built with gcc-3.3.5. When we performe the emerge -e system we are compiling all the packages including the gcc with the existing gcc-3.4.4... so after that we have a system totally built with gcc-3.4.4... it isn't necessary to use emerge -e system again.

sorry about my poor english, trying to develop it  :Wink: 

cheers:D

----------

## kueitao

I'm sorry about my poor English, as Dark_Cloud is. It seems I am not able to drive nightmorph to the point. Except for the issues related to the old libstdc++ and the "make (profiled)bootstrap", for which He didn't reply to my last post, I suppose...

Please read carefully the following from Dark _Cloud. I hope He is better than me in showing the issue:

 *Dark_Cloud wrote:*   

> Sorry, but i still disagree with you... in 7.2.4 Rebuilding the System Toolkit the toolkit was totally rebuilt and at the final of that we had a working gcc-3.4.4 and all the packages (of course) built with gcc-3.3.5. When we performe the emerge -e system we are compiling all the packages including the gcc with the existing gcc-3.4.4... so after that we have a system totally built with gcc-3.4.4... it isn't necessary to use emerge -e system again.
> 
> sorry about my poor english, trying to develop it 
> 
> cheers:D

 

I'll try even a better approach by pasting from the guides. Please remind that I'm interested only in installation with gcc-3.4.4 that is the one I argue it is wrong.

The first quote is from installation with  gcc-3.4.3  and it is the one I consider  good , except for the "-e" option:

 *Quote:*   

> 
> 
> 7.2.5 Rebuilding the System Toolkit
> 
>  Now its time to rebuild the toolkit. We'll start off by recompiling glibc, binutils, gcc, and by updating portage. This will rebuild our GCC 3.4.3 compiling toolkit (which had previuosly been compiled with GCC 3.3.5) with the GCC 3.4.3 compiler, taking advantage of our new USE flags and CFLAGS compiler settings. 
> ...

 

The second quote is from installation with  gcc-3.4.4  and it is the one I consider to be  wrong :

 *Quote:*   

> 
> 
> 7.2.4 Rebuilding the System Toolkit 
> 
>  Now its time to rebuild the toolkit. We'll start off by recompiling glibc, binutils, gcc, and by updating portage. This will rebuild our GCC 3.4.4 compiling toolkit (which had previuosly been compiled with GCC 3.3.5) with the GCC 3.4.4 compiler, taking advantage of our new USE flags and CFLAGS compiler settings. 
> ...

 

Do you, nightmorph, see the differences between them? The two guides aren't identical despite what you assert... How can you explain it? Furthermore from the first guide you can see that there's no need for an old libstdc++ installation as I pointed out even before reading that document (installation with gcc-3.4.3), because I was only trying an installation with gcc-3.4.4.

----------

## Bob P

the answer:  STATICALLY RETAINED LIBRARIES.

the need to perform redundant compilations to purge the system of statically retained libraries is a well established fact.  those who understand the nature of the problem accept the need for redundant compilation.  those who do not understand the nature of the problem tend to be the ones who start agruments about it.

if the guide doesn't suit your needs, you don't have to use it.  but please, don't use your theoretical explanations to try to prove that the guide is wrong.  over 100,000 people have installed using this method.  it started off in theory using methods similar to what you are suggesting, and it has refined to its current state of revision by trial and error.  the guide is written the way it is written because that method results in a system that works reliably.  the suggestions that you are arguing would result in a system that would not work reliably. 

please try to accept the fact that the Guide is written the way it is because this is the way that you have to do it.  please don't argue that the Guide needs to be changed just because you don't fully understand what the Guide is doing.  we've had 100,000+ test builds refine the installation method, and we won't consider changing it just because a couple of people who don't understand our methods start an argument about it.

the reasons for the steps are clearly outlined in the hundreds of pages of posts in the multiple threads related to this installation method.  if you don't understand what is being done and why it is being done, please don't ask us to explain it for you.  everything has already been well documented, and all that you need to do is read the threads to understand the logic.

best of luck.

----------

## Bob P

old versions of gcc used to pull in libstdc++-v3 as a dependency.  new ones don't.  the toolkit build fails if you fail to install libstdc++, so the step has been added manually.  there's your answer.

----------

## Dark_Cloud

Thanks for the answer, but on the other hand, you dont need to be rudy, i personally looked for the answer, read you posts and couldnt find it. 

The reason i argued against you was: you said the gcc-3.4 guide was EXPERIMENTAL and i couldnt find the emerge -e system && emerge -e system in the gcc-3.4.3 guide (that is more stable and well-tested), there inst many differences between the two guides, so i thought it could be a mistake. I dont blindly follow what people say, that's why i came here and tried find the answer.

thanks for guide and sorry about any disagreement

cheers  :Very Happy: 

----------

## kueitao

 *Dark_Cloud wrote:*   

> Thanks for the answer, but on the other hand, you dont need to be rudy, i personally looked for the answer, read you posts and couldnt find it. 
> 
> The reason i argued against you was: you said the gcc-3.4 guide was EXPERIMENTAL and i couldnt find the emerge -e system && emerge -e system in the gcc-3.4.3 guide (that is more stable and well-tested), there inst many differences between the two guides, so i thought it could be a mistake. I dont blindly follow what people say, that's why i came here and tried find the answer.
> 
> thanks for guide and sorry about any disagreement
> ...

 

Ok! the Author says that the reasons behind operating "emerge - system", in the old guide, and "emerge -e system && emerge -e system", in the new guide have already been explained in a lot of different places, doesn't He? 

With this information, have you Dark_Cloud found out where the subject is treated and explained? I'm still searching but I don't find anything closely related to that subject.

I'm sorry too about his disagreement but I think he could answer to this special question that I don't see is treated anywhere. Because He asks in his guide to communicate him suspicious bugs this is exactly what we have done, I suppose... Obviously this is not what he meant.

However, just for people that "dont blindly follow what people say", like Dark_Cloud, this is my personl experience:

I have run the first "emerge -e system", then I copied in my home directory some important executables (like Bash) that were emerged at this first round. After I run "md5sum" on them and saved the hashes. Then I run again "emerge -e system", as it is stated in the new guide we are discussing about. At the end I used both "diff" and "md5sum" on the same files I had saved before. As everyone can imagine there was no difference between those file. 

I must conclude there is absolutely no need to run "emerge -e system" twice, one after another, as it is stated in the new guide.

Notwithstanding what the author says I like his guide  :Cool:  and I thank him for providing it, but I will continue to use it the way I have expalained here, because I see those redundances.

I will continue to use it this way at least until someone is able to explain carefully why in the old one (gcc-3.4.3) we read and need only one "emerge -e system" while in the latest (gcc-3.4.4) we read and need "emerge -e system && emerge -e system". 

None has yet provided any answer for a so simple question.

PS.: With a little trick I was able to "emerge -e system" without that old libstdc++ that no one needs. But this is another story...

----------

## Bob P

 *Dark_Cloud wrote:*   

> Thanks for the answer, but on the other hand, you dont need to be rudy, i personally looked for the answer, read you posts and couldnt find it. 
> 
> The reason i argued against you was: you said the gcc-3.4 guide was EXPERIMENTAL and i couldnt find the emerge -e system && emerge -e system in the gcc-3.4.3 guide (that is more stable and well-tested)

 

Nope.  The information about performing two emerge -e systems is in the 3.4.3 version of the Guide.  You just haven't read the entire thread.

----------

## Bob P

 *kueitao wrote:*   

>  *Dark_Cloud wrote:*   Thanks for the answer, but on the other hand, you dont need to be rudy, i personally looked for the answer, read you posts and couldnt find it. 
> 
> The reason i argued against you was: you said the gcc-3.4 guide was EXPERIMENTAL and i couldnt find the emerge -e system && emerge -e system in the gcc-3.4.3 guide (that is more stable and well-tested), there inst many differences between the two guides, so i thought it could be a mistake. I dont blindly follow what people say, that's why i came here and tried find the answer.
> 
> thanks for guide and sorry about any disagreement
> ...

 

sorry to disappoint you guys, but my purpose here is not to provide free personalized tutorial services for everyone who isn't up to speed  -- my purpose here is to write-up an installation method that will work if you follow it -- nothing more.

the Guide works as it is written.  if you don't think that steps are necessary, nobody's forcing you to perform them.  you just need to realize that if you choose not to follow the Guide and your system breaks, then you get to keep the pieces.  you shouldn't come back here looking for support.  there's nothing rude about my telling you that.

i know that this will disappoint you, but i am not going to comb through the threads to look for hyperlinks to tutor you on the things that you need to know as a prerequisite for using the Guide.  i just don't have the time.  many people who haven't been up to speed have just chosen to accept the Guide for what it is, and follow it, even though they may not fully understand what they are doing.  i find it a little surprising that some people who are in the same boat of inexperience would take the opposite tack and start an argument that is founded upon a lack of understanding on their part.

unfortunately, knowledge requires study and there's no shortcut in obtaining knowledge.  as a practical matter, you're asking about one of the most esoteric problems that are encountered in building Gentoo -- why Gentoo doesn't work the way it is supposed to work, and what needs to be done to fix the problem.  these are the kind of problems that only the most experienced Gentoo users are very familiar with.  even though i've spent alot of time using my experience to write the Guide to help people , i don't have enough time to personally educate everyone on the forums to bring them up to my level of expertise on this subject.  besides, i think that most users are looking for a quick and dirty answer and wouldn't want to spend the time that it would take to learn everthing that they need to know to really become up to speed.

if you are interested in learning, i have provided you with keywords that you can use with the board's SEARCH function to find threads that contain the information that you need to know to get you started.  at this point, it is up to you to make the choice of performing the search and reading  the information or not performing the search and not reading the information.  

if you choose to do the search and find the information, then eventually your questions will be answered by your reading.  if you choose not to do the search, you won't find the information and this will be a case of my leading a horse to water, only to find that he doesn't want to drink.  that's as far as i can go, as i don't have the time to spoon-feed everyone who doesn't understand the nature of the problem with statically retained libraries.  

suffice it to say that there's a difference between the theory of how Gentoo/GCC/portage are supposed to work in theory, and how they actually perform in practice.  many people have already made theoretical arguments like yours about how the install should work -- only to find that they run into problems.  this Guide has been designed from practical experience to circumvent those problems.    experienced Gentoo users are expected to understand the concept, and that is one of the reasons that the warnings at the beginning of the Guide state that its for advanced users only,   

if the logic of the Guide doesn't make sense to you, then this Guide is not appropriate for your level of expertise.  i'm not trying to be snooty by saying that, those are just the facts and maybe the Gentoo Installation Handbook would be better suited to your needs.  in the final analysis, you have the choice to follow the guide or not to follow the Guide.  nobody's forcing you to follow it.  i find it amusing, though, that you are so vehement in your denial that information exists just because you weren't able to find it.

again, my apologies for providing free support services that aren't up to your expectations.  unfortunately i don't have the time to tutor everyone that comes along on the forums.  if you still need more information about this, i would focus on the posts by @robmoss, @moocha and @bobp in the Portage & Programming forum that relate to properly rebuilding the toolkit.  if you still have trouble, perhaps you should start a thread there asking why its sometimes necessary to perform  emerge -e system twice.  i'm sure that there are plenty of people who could help.

have fun.   :Wink: 

----------

## Dark_Cloud

 *Dark_Cloud wrote:*   

> 
> 
> The reason i argued against you was: you said the gcc-3.4 guide was EXPERIMENTAL and i couldnt find the emerge -e system && emerge -e system in the gcc-3.4.3 guide (that is more stable and well-tested)

 

I didnt read the entire thread (gcc-3.4.3), the fact is that i read the guide, as i said! I wanted to use the gcc-3.4.4 so, i just read its thread (fully)

 *Bob P wrote:*   

> i know that this will disappoint you, but i am not going to comb through the threads to look for hyperlinks to tutor you on the things that you need to know as a prerequisite for using the Guide. i just don't have the time. many people who haven't been up to speed have just chosen to accept the Guide for what it is, and follow it, even though they may not fully understand what they are doing. i find it a little surprising that some people who are in the same boat of inexperience would take the opposite tack and start an argument that is founded upon a lack of understanding on their part.

 

i dont consider myself an experienced gentoo, still have many things to learn... but the statically retained libraries problem was something i really could link with the two emerge -e system, just wanted you to ensure it. Follow something i can not understand is a thing i will not do, one of the reasons i use linux is because i can understand what it do. Inexperience of my part? maybe, but im here to get the knowledge, no one knows everything.

cheers  :Very Happy: 

----------

## Dark_Cloud

the answer to the emerge -e system && emerge -e system related questions will be found at the other guide Stage 1/3 Installation Guide for 2005.0 and GCC 3.4.3

for an example of problem take a look at the second page, @moocha and read @Bob P's reply

cheers  :Very Happy: 

----------

## Bob P

this reply will get the Blue Treatment so that its easy for other people to find.  

one thing that really helped me understand the toolkit build order from a theoretical standpoint is the linux from scratch documentation.   but even that only gives theoretical considerations about why particular packages should be built in any particular order.  it doesn't really address the somewhat convoluted way that we're building Gentoo because Portage doesn't build things in the proper order.  redundant system/world compilations are the textbook way to address this problem via a brute-strength approach.

many new users have focused upon the fact that Package A gets compiled X number of times, as if the number of compilations is some sort of indictment of the building method.  these people tend to miss the nuances about why you need to use the same version of the compiler to build itself -- the compiler that was used to build the compiler that builds their compiler needs to be the same compiler -- and how much redundant compiling is necessary to make that happen.   :Confused:    granted, it does seem somewhat rediculous, but it really isn't.

if you were to read robmoss' posts about how to rebuild the system, he would suggest that you do the following every time that a major toolkit component is upgraded:

```
emerge -e system && emerge -e system && emerge -e world && emerge -e world
```

that approach is necessary because Portage does not build things in the proper order, and you have to make multiple passes in compiling to assure that packages are compiled against the proper packages.  the logic behind the need for each step has already been beaten to death in the Stage 1/3 threads, so i won't reiterate it here.

in the Stage 1/3 Guide, I've tried to trim-down the total compiling time in comparison to the robmoss method, so that only the things that really need to be compiled are compiled.  that's why we build the toolkit first (redundantly for the reasons stated earlier) and then use a properly built toolkit to perform two emerge -e systems to purge all remnants of code generated by an obsolete compiler from the system.  then, when the system packages are properly built, the world files are populated and you only have to build them once instead of twice.  this approach is alot quicker than the robmoss approach (especially if you have alot of world packages like X), and accomplishes the same thing in much less time.  experience has shown that trying to cut out one of the emerge -e systems (like i did in previous versions of the Guide) just don't work -- the toolkit is never built properly failures inevitably result.

rebuilding a system toolkit is a very difficult procedure to get right.  traditionally, you need to bootstrap in order to do this properly, especially if you are changing architecture or chost specifications.  unfortuantely, bootstrapping into the testing branch in Gentoo is a risky venture at best, not to mention the circular dependency problems that are often encountered with Stage 1 installs.  The Stage 1/3 method solves all of those problems at the expense of taking an awful lot of time to complete.

the warning in the preface to the Guide specifically cautions the user the time commitment that is required to perform this install properly.  no, it wasn't a joke, and yes, every step is really necessary for the system to perform with integrity.

hth.

----------

## kueitao

 *Dark_Cloud wrote:*   

> the answer to the emerge -e system && emerge -e system related questions will be found at the other guide Stage 1/3 Installation Guide for 2005.0 and GCC 3.4.3
> 
> for an example of problem take a look at the second page, @moocha and read @Bob P's reply
> 
> cheers 

 

Thank you. Now that I have just found it I cannot disagree anymore with that logic. I'm sorry I couldn't understand that reading the entire thread on installing with gcc-3.4.3 was essential to fully comprehend those mechanisms. It's my fault I supposed that only the guide itself on gcc-3.4.3, to which anyway I didn't give much attention because I was trying to install with gcc-3.4.4, was enough to make assumptions on how many "emerge -e system" were needed.

Cheers.

----------

## kueitao

 *Bob P wrote:*   

> this reply will get the Blue Treatment so that its easy for other people to find

 

[cut some lines]

 *Bob P wrote:*   

> 
> 
> ```
> emerge -e system && emerge -e system && emerge -e world && emerge -e world
> ```
> ...

 

[cut some more lines]

Thank you for the above quoted code and your detailed explanation on the subject. Now it's all very clear (also with contribution of the whole reading of "installation 1/3 with gcc-3.4.3". As I wrote in the last post, I'm sorry I couldn't understand I should had read the whole thread, not stopping at the end of the guide.  :Embarassed: 

Regards.

----------

## teilo

Shouldn't you be including an emerge linux-headers before rebuilding glibc?

----------

## -=GGW=- $ol!d $n4>|e

YOU sir!, are a god among men.  :Smile: 

----------

## Bob P

 *teilo wrote:*   

> Shouldn't you be including an emerge linux-headers before rebuilding glibc?

 

why?

----------

## Bob P

wow, i just did a quick glance at the Documentation Tips & Tricks forum.  It seems that the 3 versions of the Stage 1/3 Guides have reached a total viewing of 125,432 page views, and the support threads have reached a total of 84,031 page views, for a total of 209,463 page views (not counting any of the Jackass! threads).

the only other installation guide that comes close is ali3nx's excellent Stage 1 tut, currently at 118,584 page views.

who would have thought that this installation method would have caught on like wildfire?

----------

## 96140

Yea, verily, it is a like unto a force of nature.

----------

## COiN3D

Hi Bobp,

great work again. But haven't you forgotten a "mkdir /mnt/gentoo" ?  :Smile: 

----------

## Tashiro

Hi Bob,

Just a little thing about setting the time, you wrote: *Quote:*   

> 6.4.3 Get it Right for Daylight Savings Time.
> 
> The previous example showed how to select a city when setting the timezone symlink. It is my opinion that you should always choose a city that is in your time zone, and use the city to set the time zone symlink. You should NEVER choose a time zone as your symlink for the setting the time zone. Here's why:
> 
> I live in Chicagoland. By setting the timezone symlink to the nearest major city, Chicago, I don't have to worry about implementing Daylight Savings Time. Linux is smart enough to spring forward and fall back so that no changes to the system time are necessary on my part. This past weekend, when Chicago changed from Central Standard Time to Central Daylight Time, I watched with glee as the clocks on all of my linux PCs ticked from 01:59:59 CST to 03:00:00 CDT. (Just in case you were wondering, THAT is confirmation that I am a basement-dwelling linux g33k!) If I had made the mistake of setting the timezone symlink to CST, then linux would have kept my PC's clock on CST, even though the city that I live in had switched to CDT. In this case, I would either have to manually change my clock over from CST to CDT, or learn to live with a PC who's clock is off by an hour.
> ...

 

But if I set my time to CET it does adjust to CEST. When the clock hits 032701592005 CET it will go to 032703002005 CEST once it reached 032702002005 CET. I checked it myself.  :Cool:     (can I join the club of  basement-dwelling linux g33ks?)

Tashiro

----------

## Bob P

 *Tashiro wrote:*   

> Hi Bob,
> 
> Just a little thing about setting the time, you wrote: *Quote:*   6.4.3 Get it Right for Daylight Savings Time.
> 
> The previous example showed how to select a city when setting the timezone symlink. It is my opinion that you should always choose a city that is in your time zone, and use the city to set the time zone symlink. You should NEVER choose a time zone as your symlink for the setting the time zone. Here's why:
> ...

 

well, whether you can join the club of basement-dwelling linux g33ks depends upon other things, like whether you're a g33k who dwells in a basement.   :Wink: 

regarding timezones, my answer is still no -- to have timezones work properly 100% of the time you need to either: 1) specify where you are by specifying the city and not just the time zone (and linux will set the status of the DST observance toggle for you), or 2) specify the timezone AND whether or not DST is observed.  

in the first case, linux knows how to set the DST toggle based on your city.  in the second case, you need to properly specify the status of the DST toggle or specifying the time zone will not be enough to get DST right.

granted, the exceptions to this rule are rare, and you're not likely to encounter them unless you live in some parts of Indiana or in Hawaii, where Daylight Savings Time is not observed.  if you were to be in one of those locales and you were to specify CST or CDT, then your PC would switch back and forth inappropriately.  Indianapolis stays on EST year round, so its in-sync with Chicago during CDT and New York during EST.  only basement dwelling ub3r-g33ks know this kind of stuff.   :Cool: 

----------

## esson

Thank you but is it possible to get it in a printable version? I'm printing at my work now so I don't really care but what about those who can't do that. Just some input  :Smile: 

cheers!

----------

## 96140

The guide is printable. Either just directly print the entirety of the first page of this thread, or highlight, copy, and paste the steps of the instructions to a text editor, and then print that.Last edited by 96140 on Tue Aug 16, 2005 12:15 am; edited 1 time in total

----------

## Bob P

 *esson wrote:*   

> Thank you but is it possible to get it in a printable version? I'm printing at my work now so I don't really care but what about those who can't do that. Just some input 
> 
> cheers!

 

there is a PDF version available though its a bit outdated.  follow the links.

----------

## Bob P

 :Arrow:  PDF Updated.

----------

## Enibevoli

Preface: I have followed the "official" Gentoo installation guide for 2005.1 (don't be afraid, my question isn't related to or depending on 2005.1) for getting a base Gentoo x86 system running. But since I wanted to make use of new gcc 3.4.x flags, in particular "-march=pentium-m", I am following your guide to make the upgrade from gcc 3.3.5 to 3.4.4. So far, no problems.

But in addition/comparison to your guide, I already have a handful of packages already emerged (syslog-ng, vixie-cron, etc.), and I found the whole list of packages in /var/lib/portage/world. Looking at your comments about robmoss' method to make sure packages are recompiled correctly, my question is:

When I follow your guide but already have some packages installed, is it enough to just "emerge XY YZ ..." for those packages after doing "emerge -e system && emerge -e system", or is a "emerge -e world && emerge -e world" necessary - which would implicitly also re-emerge packages in system twice? Maybe a note in your guide would be nice for those who have for whatever reasons a small set of additional packages installed (including those who stumbled upon it after the initial Gentoo installation).

----------

## Bob P

that question comes up every now and then.  the scope of this guide is limited to installing, not rebuilding complete systems, even though it does a toolkit rebuild during the course of the install.

reading your question, it seems that you don't have a firm grasp of what the difference is between "system" packages and "world" packages.  if you have packages already installed, they'll get rebuilt if you perform all of the redundant emerges.

when in doubt:  emerge -e system && emerge -e system && emerge -e world && emerge -e world.  if you read robmoss' posts about this subject (or the many reiterations of this subject in the various Stage 1/3 threads), the reason for each step should be very clear.

----------

## Enibevoli

 *Bob P wrote:*   

> reading your question, it seems that you don't have a firm grasp of what the difference is between "system" packages and "world" packages.  if you have packages already installed, they'll get rebuilt if you perform all of the redundant emerges.

 

Aye, you're right about the firm grasp.  :Wink:  The man page of emerge simply reads

```
world contains all of the packages in system, along with any other packages listed in /var/lib/portage/world
```

but fails to inform what exactly is in system (or where one can find this information; I'm sure I will find this information finally though). From what I could tell reading the man page, "emerge world" would implicitly also emerge all packages in system, which was already done twice in your guide. My /var/lib/portage/world has only 17 lines currently with just some basic packages such as grub, nano and coldplug. I hoped to find a way to exclude already-emerged packages listed in system by calculating the subset of packages "world - system" and just recompiling the remaining subset twice to safe precious CPU time. 

 *Bob P wrote:*   

> when in doubt:  emerge -e system && emerge -e system && emerge -e world && emerge -e world.  if you read robmoss' posts about this subject (or the many reiterations of this subject in the various Stage 1/3 threads), the reason for each step should be very clear.

 

Thanks, will do.

----------

## kimchi_sg

 *Enibevoli wrote:*   

> The man page of emerge simply reads
> 
> ```
> world contains all of the packages in system, along with any other packages listed in /var/lib/portage/world
> ```
> ...

 

In recent versions of Gentoo (probably anything after 2004.2), the cascading profile system is used. This means that the "system" package set is deduced through reading /etc/make.profile/packages. If there is a "parent" file in /etc/make.profile, Portage will look for a "packages" file in the directory specified by this file (path is relative to /etc/make.profile) and add it into the "system" package set. This process continues until Portage reaches a directory that has no "parent".

----------

## Bob P

for the new users who don't want to get so far into the nuts and bolts, it may be simpler to look at it this way:  when you extract a tarball, your PC only contains system files.  after you start installing packages, they become added to the world file list.

this is really an oversimplification, but it should give you an idea what the docs mean when they say:

```
world contains all of the packages in system, along with any other packages listed in /var/lib/portage/world
```

----------

## linuxgeek

Just wanted to say that.. this guide rocks...

I did this using 2005.1 and had Zero issues...

In fact I was amazed at how stable my 2.5 Celeron system is, as in

compiling something so critical over and over and over again without

a hiccup. It is ROCK wait scratch that it is DIAMOND solid... : )

I can tell there is more responsiveness in the system now... That is what I

have seen so far... 

Why is it so fun being on the Bleeding Edge? Cause it is...

Thanks for a great discovery and a great guide...

Dare I say it! GENTOO ROCKS!!!! 

Tim

----------

## Bob P

DIAMOND solid?  i like that.   :Very Happy: 

----------

## nautiazn85

I just noticed that portage got rid of gcc3.4.4 ebuild and now has gcc3.4.4-r1. Are there any differences? If so should I recompile my whole system?

----------

## 96140

Read the release notes for 3.4.4-r1. I haven't checked it, but usuall gcc -r* revisions are nothing more than minor bug fixes or ebuild changes. Wait until the reports from other users start trickling in to the forums or mailing lists; that way, you can see all the new bug reports (if any) or performance enhancement reports (if any) for the new revision.

----------

## kimchi_sg

 *nautiazn85 wrote:*   

> I just noticed that portage got rid of gcc3.4.4 ebuild and now has gcc3.4.4-r1. Are there any differences?

 

 *GCC's Changelog, which you can view by going to packages.gentoo.org wrote:*   

> *gcc-3.4.4-r1 (27 Aug 2005)
> 
>   27 Aug 2005; Mike Frysinger <vapier@gentoo.org> +gcc-3.4.4-r1.ebuild:
> 
>   Push out cumulative changes (especially #87631).

 

----------

## WTFman

 *linuxgeek wrote:*   

> Just wanted to say that.. this guide rocks...
> 
> I did this using 2005.1 and had Zero issues...
> 
> In fact I was amazed at how stable my 2.5 Celeron system is, as in
> ...

 I have a celleron processor too and it is complete crap! if it worked for you I'd be willing to bet it will work for me too! Going to try it  :Smile: 

----------

## 96140

(Originally posted in Jackass! 2005.1. This is more relevant to Stage 1/3--either 2005.0 or 2005.1--users who have to recompile their system with every toolchain update.)

You know, I don't think we need to have glibc ~x86 in /etc/portage/package.keywords anymore.

IIRC, it was in there because 2.3.5-r1 was needed to support the other toolchain components. However, within the last few days, glibc-2.3.5-r2 was marked stable (on x86). I've rebuilt my toolchain with it and am currently on the last "emerge -e world" step of the subsequent recompile.

Now that it's stable, glibc ~x86 can be removed from package.keywords, since 2.3.5-r* (the series unmasked when it was still ~testing) is stable. Also, Stage 1/3 users can avoid the (very relatively) frequent updates to glibc ~x86 by removing it from package.keywords--new versions of glibc take a long time to be marked stable on x86, and the current stable glibc-2.3.5-r2  is the only version needed to support GCC-3.4.4.

A good idea? Yea/Nay?

I've never liked running with any ~unstable branch package enabled, except when absolutely necessary. As of right now, the only packages in /etc/portage/package.keywords that are still in the unstable Portage tree are libstdc++-v3-3.3.6 and gcc-3.4.4-r1. Every other package in the file, even though it's keyworded ~x86, has actually been moved out of ~unstable and into stable. In fact, there are no ~unstable ebuilds for those packages; if you've updated your system within the last several days, then you're using toolchain components that are stable.

So, given all that  :Wink:  , is there any need to keep the packages besides gcc and libstdc++-v3 in package.keywords? Of course, the obvious potential problem is that a new revision of gcc-3.4.4 comes out, or 4.x is marked ~x86, and it depends on an ~unstable toolchain package. However, I think this is unlikely, as there is no other ~unstable toolchain package waiting in the wings. There's a couple that are hardmasked/unstable, but they are unlikely to move to ~x86 for a long, long time, if at all.

----------

## Bob P

 *nightmorph wrote:*   

> (Originally posted in Jackass! 2005.1. This is more relevant to Stage 1/3--either 2005.0 or 2005.1--users who have to recompile their system with every toolchain update.)
> 
> You know, I don't think we need to have glibc ~x86 in /etc/portage/package.keywords anymore.
> 
> IIRC, it was in there because 2.3.5-r1 was needed to support the other toolchain components. However, within the last few days, glibc-2.3.5-r2 was marked stable (on x86). I've rebuilt my toolchain with it and am currently on the last "emerge -e world" step of the subsequent recompile.
> ...

 

Just for review, here's what the current version of the Guide uses for package.keywords:

```
# cat /etc/portage/package.keywords

~sys-devel/gcc-3.4.4 ~x86

sys-devel/gcc-config ~x86

sys-libs/libstdc++-v3 ~x86

sys-libs/glibc ~x86
```

and here's what's in the current portage tree:

```
# emerge -pv gcc gcc-config libstdc++-v3 glibc

These are the packages that I would merge, in order:

Calculating dependencies ...done!

[ebuild   R   ] sys-devel/gcc-3.4.4-r1 [3.4.4] (-altivec) -bootstrap -boundschecking -build +fortran -gcj -gtk* -hardened -ip28 (-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc -static -vanilla 27,036 kB

[ebuild   R   ] sys-devel/gcc-config-1.3.12-r2  0 kB

[ebuild   R   ] sys-libs/libstdc++-v3-3.3.6  -build (-multilib) +nls +nptl 23,410 kB

[ebuild     U ] sys-libs/glibc-2.3.5-r2 [2.3.5-r1] -build -erandom -glibc-compat20 -glibc-omitfp -hardened -linuxthreads-tls (-multilib) +nls +nptl -nptlonly -pic -profile (-selinux) +userlocales 15,628 kB

Total size of downloads: 66,075 kB
```

the way that package.use is currently configured, it doesn't enable GCC in the stable branch.  it only enables GCC 3.4.4 in the stable branch, so it won't pick-up other versions of GCC.  so in some respects it doesn't matter if GCC 4.x gets marked stable or not, as GCC 4.x is slotted and so is GCC 3.4.4.  

i guess we don't have to have gcc-config marked in the testing branch, but there have been an awful lot of bugs in gcc-config that silently get fixed, so it seems to make sense to stick with a testing branch ebuild there.

now as far as glibc goes, i guess you could remove the ~arch statement for glibc if you're confident that the current version of  glibc is going to remain in the stable branch.  there seem to be alot of ebuilds that reversibly get marked stable -- alot of them tend to wander back and forth between the stable branch and the testing branch.  so if anyone's thinking about removing the ~arch specification, i'd recommend that you keep an eye on the status of the ebuild as an "arch" or an "~arch" package.  beyond that, i think that choosing between ~arch and arch for glibc amounts to 6 of one or half-a-dozen of the other.    :Confused: 

in the big scheme of things, its a tradeoff between stability and the bleeding edge.  this guide has always been about both, but the more conservatively minded users might want to use the arch version of glibc.  unfortunately, when patches get applied, history has shown that the devs patch across both branches and they tend to break both testing branch and stable branch packages.  in the big scheme of things, i wonder if the decision really matters...

----------

## ocbMaurice

I was wondering if I could reduce the compile time and I think it's possible.

Specially the doubled emerge -e system bothered me, altough I understand why it is needed:

1) linked libraries may get removed if a newer version of that library is emerger later

2) included headers of libraries (that get compiled/updatet later) may not be compatible with the updated version

Anything else that could make a second emerge necessary? 

A few people already suggested to use ccache earlier to specially speed up the second "emerge -e world". This partially has been discussed in Installing Gentoo 2004.3: Stage 1 NPTL on a Stage 3 Tarball, but there seems to be no indication wheter or not it is save to do so. One question was if ccache would notice that another compiler is used. To check that I took a look at the ccache sources. In the file ccache.c (~ line 320) I found an answer. 

```
 /* the compiler driver size and date. This is a simple minded way

    to try and detect compiler upgrades. It is not 100% reliable */

 if (stat(args->argv[0], &st) != 0) {

   cc_log("Couldn't stat the compiler!? (argv[0]='%s')\n", args->argv[0]);

   stats_update(STATS_COMPILER);

   failed();

 }

 hash_int(st.st_size);

 hash_int(st.st_mtime);
```

Ccache indeed uses the compiler "version" to compute the cache hash. Ccache simply stats the used compiler and includes the size and the modification time for its hash function. Here it gets a bit complicated. Ccache will stat /usr/bin/i686-pc-linux-gnu-gcc which is not the actual compiler but a wrapper provided by gcc-config (so it can invoke the selected compiler). Anyway, it seems that the gentoo developers have done something to support ccache with gcc-config. Gcc-config will change the modification time of /usr/bin/i686-pc-linux-gnu-gcc (and /usr/bin/gcc, since it is a hardlink to the former) to the same as the selected compiler (as far as I can tell).

It should not be a problem to use ccache after we have built the toolkit a second time (before we start to emerge -e system). The preprocessing and linking is still done (not cached by ccache), so the possible problems mentioned above should still be resolved, IMHO it's still not optimal to simply use emerge -e system, as it IMHO is not necessary to compile the toolkit a third and a fourth time (since these packages should not depend on any other packages, but I'm not 100% sure, maybe someone can confirm this). It would also update the mtime of the compiler so ccache would not have any effect (not sure if emerge gcc will update the mtime of /usr/bin/gcc itself if gcc-config is not called again).

I used this perl oneliner to avoid the inclusion of gcc-config, gcc, binutils, glibc and libstdc++-v3 in emerge -e system.

```
# emerge -ep system | perl -e 'while(<>) { /\]\s+([^\/]+\/.*?)\-[0-9][0-9\-\._]*.*?\s*$/ and not $1=~m/^[^\/]+\/(?:gcc\-config|gcc|binutils|glibc|libstdc\+\+-v3)$/ and $p.=$1." " } system "emerge $p"'
```

I'm not sure if the used regular expression will parse all package names correctly, but it did work for me (if there is a problem, emerge should issue a warning when invoked). Of course you still would need to call this two times. I'm not sure how much the compile time is reduced if you use ccache and the above oneliner, but I'm sure it will save at least "some" time.

greets, Maurice

----------

## DOSBoy

```

emerge -p gcc glibc binutils libstdc++-v3 | genlop -p

```

Says 8 hours, 42 minutes for my PII 366. Note that parts may have been built with distcc (not that much though), and it should be doubled for 2 emerge -e systems.

----------

## Bob P

for obvious reasons, i would not recommend implementing ccache until after the toolkit has been completely rebuilt.

on the subject of trimming down the compile time -- one has to be cautious about chasing false economy when you do things like that.  sure, there are lots of methods to cut down on compile time by eliminating steps that appear to be unnecessary.  feel free to experiment, but when you deviate from the Guide and you encounter problems, DO NOT post to the Stage 1/3 threads looking for support.  start your own thread to troubleshoot your new installation method.   :Wink: 

the Guide has been extensively tested for reliability.  the shortcuts have not.  take that for what its worth.

i would also point out that this Guide specifically warns the user about the time commitment that is required, and that the Guide may not be suitable for everyone.  rather than emasculating the Guide by cutting parts of it out in the interest of saving time, impatient users are recommended to choose an installation method that is better suited to their needs.    :Idea: 

----------

## Bob P

KDE users may want to reconsider the use of CXXFLAGS:

http://planet.gentoo.org/developers/flameeyes/2005/10/11/that_is_not_working_man

----------

## WTFman

Funny, KDE works fine for me, XFCE on the other hand seems buggy and unstable, could just be my hardware, but KDE works fine!

----------

## cokey

i take it  *Bob P wrote:*   

> Copyright (c) 2005 Bob Predaina. All Rights Reserved

 was a joke...

----------

## odejoy

n/mLast edited by odejoy on Mon Nov 07, 2005 5:04 am; edited 1 time in total

----------

## Mr. Garr

 *Quote:*   

> Upon completion of the rebuild of the compiling toolkit, we will recompile the entire system to assure that our entire toolkit has been compiled using GCC 3.4.4 and our hardware-specific settings.
> 
> The result will be a 3.4.4 tooklit and an entire system that is built with a 3.4.4 toolkit, that was built with a 3.4.4 toolkit. 
> 
> ```
> ...

 

is it a mistake or it realy should be like this? (the code thingy)

----------

## Monkeh

 *Mr. Garr wrote:*   

>  *Quote:*   Upon completion of the rebuild of the compiling toolkit, we will recompile the entire system to assure that our entire toolkit has been compiled using GCC 3.4.4 and our hardware-specific settings.
> 
> The result will be a 3.4.4 tooklit and an entire system that is built with a 3.4.4 toolkit, that was built with a 3.4.4 toolkit. 
> 
> ```
> ...

 

It's not a mistake.

----------

## Bob P

the Guide has been through 4 major revisions in the past year.  i think all of the major kinks have been beaten out of it.    :Wink: 

----------

## scharkalvin

Can I follow this guide, but start out with a stage 3 tarball

from the gentoo 2005.1 install branch?

I have a K6-300 system (Asus MB with 256MB of ram).

I'd like to optimize the system around the K6 specific

march parameters.  Install time isn't an issue (so long

as the power doesn't fail in the middle!)  I'd like to get

an old war horse computer up doing something usefull.

I'll probably install XFCE-4 instead of Gnome or KDE, I'm

using XFCE on an old PIII and it's not a bad desktop.

----------

## Bob P

in case you missed the notices, documentation tips & tricks is not a support forum.  please post support questions in the support thread.  if you're not too busy to read the support thread before you post, you'll find the answer there.  i'm too lazy to retype it.

----------

## scharkalvin

 *Quote:*   

> in case you missed the notices, documentation tips & tricks is not a support forum. please post support questions in the support thread. if you're not too busy to read the support thread before you post, you'll find the answer there. i'm too lazy to retype it.

 

\

Not at all.  There are so many side threads on this one I just got lost.

You've been googled to death!

----------

## eyeL

when it says

9.2 Building the Kernel Symlink

Code:

# rm /usr/src/linux

# cd /usr/src

# ln -s linux-2.6.12-gentoo-r6 linux

any way to make it a 2.6.14 kernel right here?

----------

## Bob P

sure.  change what you type.    :Wink: 

----------

## eyeL

Ok, I just wanted to make sure that I was able to get the 2.6.14 kernel while installing, instead of rebuilding my kernel later.

----------

## Bob P

your question worries me.  this is an advanced/expert guide, and your question makes it sound like you're not at all familiar with using portage.  

if you have problems with the Stage 1/3 Guide then I'll try to help, but if you have Gentoo Fundamentals problems i'll have to point you to the Forum, as the time that i have to offer support is limited.

----------

## prolific

right now i have a new system built on gcc 3.3.5 running on x86... if i put ACCEPT_KEYWORDS="~x86" in my make.conf file and then do a emerge -u world, i know this will break the system a little bit .. after doing this will doing these two emerges fix everything? 

emerge glibc binutils libstdc++-v3 gcc portage 

emerge -e system && emerge -e system

----------

## Bob P

 *prolific wrote:*   

> right now i have a new system built on gcc 3.3.5 running on x86... if i put ACCEPT_KEYWORDS="~x86" in my make.conf file and then do a emerge -u world, i know this will break the system a little bit .. after doing this will doing these two emerges fix everything? 
> 
> emerge glibc binutils libstdc++-v3 gcc portage 
> 
> emerge -e system && emerge -e system

 

if you follow the Guide, it will work.

if you deviate from the Guide, or your have a Gentoo question not related to the Guide I don't provide support.

Documentation Tips & Tricks is not a support forum.  support for the Guide is available in the Support Thread, not here.

----------

## Bob P

becase we keep getting support requests in this thread instead of in the Official Support Thread, i'm just going to remind everyone...

 *Stage 1/3 Guide wrote:*   

> 13.  If You Need Help
> 
> Remember: The Documentation, Tips & Tricks forum is not a support forum:
> 
>  *Quote:*   Documentation, Tips & Tricks
> ...

 

----------

## mtamizi

gcc-3.4.4-r1 is now stable.

----------

## scharkalvin

 *Quote:*   

> gcc-3.4.4-r1 is now stable.

 

So does this thread close up shop?

----------

## Bob P

No.   I think you're missing something.  Gentoo marking GCC 3.4.4 into the stable branch doesn't make this installation method obsolete, because Gentoo is still distributing obsolete media that uses GCC 3.3.5 and doesn't support NPTL!  You still need this Guide if you want to install from Gentoo media and end up with a decent toolkit.

Now what REALLY makes this Installation Guide obsolete is the Jackass! media.  Ever since May 2005 when Jackass! 2005.0 was released people who use a Pentium-branded processor or an Athlon-XP processor have had no good reason to install from Gentoo media or to perform a Stage 1/3 install.

----------

## warrens

 *scharkalvin wrote:*   

>  *Quote:*   gcc-3.4.4-r1 is now stable. 
> 
> So does this thread close up shop?

 

I wouldn't think so.  The stage files are still built with gcc-3.3.6, so the tool chain would still need to be rebuilt to build the system with gcc-3.4.4-r1.  It could quiet this thread after Gentoo 2006.0 is released if gcc-4.x.x is not in ~arch by then, but should be back in full-swing after gcc-4.x.x becomes available in ~arch.  It will be intersting to here what BobP has to say.  :Smile: 

----------

## scharkalvin

 *Quote:*   

> Gentoo is still distributing obsolete media that uses GCC 3.3.5 and doesn't support NPTL! 

 

I guess none of the stage 3 tarballs have been updated to include the 3.4.4 compilier

which was built by a 3.4.4 compilier along with the rest of the system.  (I should check

the date of the latest tarball on the mirrors.).  Even if the tarballs WERE built

with the latest compilier I would have to set the nptl use flag and then

emerge -e --newuse world to get the same thing.

Looks like the upgrade instructions mirror your install method, but I think they left out

a final emerge -e world.

----------

## scharkalvin

I just checked the on line package data base.

Seems gcc-3.4.4 and gcc-config no longer need the ~x86 keyword.

I'm not sure about libstdc++-v3, glibc, and binutils.  They are all current,

but a newer ebuild is available for the same downstream source.

timezone-data is still masked and needs to be in the keywords file.

----------

## Bob P

it depends which ebuilds you want.  the only ebuild from the guide that has been  marked stable this week is gcc.   there are older versions of glibc that are marked stable, but i don't use them.  you have to select timezone data, and pay close attention to what's going on with gcc-config and binutils.

in the big scheme of things, you don't need to edit package keywords and the guide doesn't need to be updated, but you can comment out certain ebuilds if you'd rather have older stable branch versions.  its all a matter of user preference.

i am not surprised that the official gentoo recommendations "mirror" what i've been doing all along.

----------

## hadees

 *Bob P wrote:*   

> No.   I think you're missing something.  Gentoo marking GCC 3.4.4 into the stable branch doesn't make this installation method obsolete, because Gentoo is still distributing obsolete media that uses GCC 3.3.5 and doesn't support NPTL!  You still need this Guide if you want to install from Gentoo media and end up with a decent toolkit.
> 
> Now what REALLY makes this Installation Guide obsolete is the Jackass! media.  Ever since May 2005 when Jackass! 2005.0 was released people who use a Pentium-branded processor or an Athlon-XP processor have had no good reason to install from Gentoo media or to perform a Stage 1/3 install.

 

Okay I sort of get that but I still am not sure why you do this

```
sys-devel/gcc-config ~x86

sys-libs/libstdc++-v3 ~x86

sys-libs/glibc ~x86

sys-devel/binutils ~x86

sys-libs/timezone-data ~x86
```

What is the advantage to using the unstable versions?

I also read some of your other posts and was wondering why the stable toolkit couldn't be used with GCC 3.4.4 and using NPTL.  Just from your warnings about unstable toolkits seems like using the stable version would be simpler.  Is it just because you want the bleeding edege or is there really a preformance upgrade.

I was also wondering about your choice of CFLAGs, They are a tad aggresive and I was wondering your reasons for using some of them.

Don't take this thread the wrong way, I am guessing your are correct but I want to learn the reasons.

----------

## Bob P

you need to pay attention to datestamps.

----------

## hadees

I did, the last posts on this were just 5 days ago and I thought the questions made sense here since you had just posted about gcc 3.4.4.  I know you have quite a few of these documentation threads and I thought I had looked at them all.  Is there an answer to these questions other places?

----------

## Bob P

this is not a support thread or a support forum.  we have a dedicated support thread that is actually a better place to ask support questions and to review the large repository of answers to support questions that have already been asked and answered.

i have to admit, i'm a bit surprised that people continue to ask for support in this thread in spite of the multiple repeated requests not to do so.  the big red warning signs are even repeated right on this page.   :Rolling Eyes:   i just don't understand how people keep missing them.  maybe they're just skipping around when they're reading the threads.

all of these questions have already been asked and answered in detail in the various Stage 1/3 theads. because i'm only one person and i'm spread rather thin with all of my gentoo related projects, i don't have the time to rehash all of these questions and answers that we have already covered in the past year.  so instead of wasting alot of time retyping everything, i'll just refer people to the other versions of the Guide AND their Support Threads to research the answers to their questions.

one thing that people have to realize is that when I created the Stage 1/3 installation method and wrote the first Stage 1/3 Guide, it was a revolutionary new way to install Gentoo, and it was an ADVANCED method for ADVANCED/EXPERT users.  that was A YEAR AGO.  

now that Gentoo has done away with the Stage 1 install in favor of a Stage 1 on a Stage 3 tarball approach, my installation method has become a standard Gentoo installation method instead instead of my pet Advanced/Expert method.  the good news is that the Community at large has become familiar enough with this method that Gentoo and the Community at large should have no problem answering anyone's support questions while I focus my attention on working on newer, more cutting edge projects.

----------

## nkmcc

Thanks Bob - nice work.    :Very Happy: 

-Neal

----------

## hadees

Sorry Bob,

I really didn't think it was a support issue because I am not having trouble with my system, your install method worked prefectly   :Very Happy: 

I just wanted to learn more about the reasons you did things the way you did.  I will go reread your other support thread.

----------

## Bob P

not a big deal, i just try to keep this thread as short as possible so that people who are trying to follow the Guide aren't obliged to read alot of unnecessary stuff.  if you post in the support thread, i'll try to help, but i have to admit that as my projectcount increases, i tend to pay less attention to the older projects that work so well that they are running on autopilot...

btw, here's a link to the first Stage 1/3 Guide in the series.  The thread is so old that it may be hard to find, but its the best starting point:

Installing Gentoo 2004.3: Stage 1 NPTL on a Stage 3 Tarball

----------

## Gotterdammerung

Just passing by to thank the manual, it help a real lot.

[]'s

----------

