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

## Bob P

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

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

The Text of This Tutorial is Copyright 2005 by Bob P and The Jackass! Project.  All Rights Reserved.

 :Arrow:  Stage 1/3 Guide for 2005.0 Now Available.   Click Here.

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

Stage 1/3 Installation for Gentoo 2004.3

WARNING:  This is an ADVANCED installation method.  The amount of time required for you to complete this type of installation will equal or exceed that of any other Gentoo installation method.  Your time will be well invested, though, as the result will be a very stable Gentoo system.  This installation method may prove to be somewhat difficult and cumbersome for users who are new to Gentoo.  It will prove especially painful for users who plan to install Gentoo old hardware.

NOTE: The Documentation, Tips & Tricks Forum is NOT a support forum.  If you should encounter problems during your Gentoo installation, please DO NOT post requests for assistance to this thread.  Please seek help in the support thread that is dedicated to this installation method.

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

Introduction

Any Gentoo installation that is performed with anything other than a Stage 3 tarball suffers from two problems:  They suffer from circular dependencies within the base system, and they have 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."

So it seems that there are 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.

Objective

This Installation Guide will describe how to perform a "Stage 1 on 3" installation of Gentoo on a Pentium-class x86 platform using 2004.3 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.3 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 is the only computer that I have left that doesn't already have Gentoo installed on it, and as I write this Guide I'm 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.  

This guide is loosely based upon a combination of the Gentoo Installation Handbook, ali3nx's Stage 1 and NPTL tutorial, and a collection of tweaks to modify these installation methods to make them compatible for installation using a Stage 3 tarball.  The adaptations that were required to make these methods work well with a Stage 3 tarball became extensive enough that it seemed worthwhile to create this thread as an independent installation guide.  Although most of this should look familiar, I'm adding my own ideas about specific optimizaitons that need to be made to take advantage of new features offered by the GCC 3.4.3 compiler.

To perform a Stage 1 Installation on a Stage 3 Tarball, 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/2004.3/livecd/install-x86-minimal-2004.3-r1.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/2004.3/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/2004.3/stages/x86/stage3-x86-2004.3.tar.bz2

# wget http://gentoo.osuosl.org/releases/x86/2004.3/stages/x86/stage3-x86-2004.3.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-2004.3.tar.bz2.md5

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

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

```
tar -xjpvf stage3-x86-2004.3.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-20050101.tar.bz2

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

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

# tar -xjvf /mnt/gentoo/portage-20050101.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

# 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 January 2, 2005 at 19:30:

```
# date 010219302005

Sun Jan  2 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 Jan  2 19:32:50 CST 2005
```

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.  

We will use a small collection of USE flags in building our base system.  You are free to add additional USE flags as needed to meet your specific system requirements.

Please note:  The inclusion of the nptl USE flag 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. The ithreads USE flag is used for the perl and libperl ebuilds.

Note that this Installation Guide recommends the stable software branch as default.  If you choose to use the testing branch, proceed at your own risk.

```
# cat /etc/make.conf

CHOST="i586-pc-linux-gnu"

CFLAGS="-O2 -march=pentium -pipe"

CXXFLAGS=${CFLAGS}

#  "x86" refers to the stable  software branch

# "~x86" refers to the testing software branch

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="sandbox ccache distlocks"

CCACHE_SIZE="512M"

USE="ithreads 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.3 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.3 is part of the unstable or "testing" branch in Portage.  Because we are using the "x86" stable branch of the software, then we need to configure Portage to enable the use of GCC 3.4.3 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 ~x86

sys-devel/gcc-config ~x86 

sys-libs/libstdc++-v3 ~x86

sys-libs/glibc ~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.

6.7.1  Activate the userlocales USE flag for glibc

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

sys-libs/glibc userlocales
```

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

To enable NPTL support we are required to use a 2.6 kernel and linux26-headers.  Unfortunately, the 2004.3 Stage 3 tarball includes linux-headers, which act as a blocker when attempting to emerge linux26-headers.  In building the toolkit, we will first unmerge linux-headers and then emerge linux26-headers.  

The linux kernel headers are typically updated only when updating a version of glibc.  As a result, we should recompile glibc after emerging linux26-headers.  We will also emerge new versions of binutils and upgrade to the current version of gcc when building our toolkit.  

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

# emerge -C linux-headers 

# emerge linux26-headers 

# emerge gcc-config glibc binutils gcc
```

Or if you prefer a one-liner:

```
# env-update && source /etc/profile && emerge -C linux-headers && emerge linux26-headers && emerge gcc-config glibc binutils 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.3

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.4 and a toolchain built with GCC 3.3.4 to compile GCC 3.4.3.  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.3 that was built with GCC 3.4.3.  

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.3.  After making necessary updates to /etc/make.conf we need to rebuild the toolkit using the new GCC 3.4.3 compiler.  The result will be a 3.4.3 tooklit, compiled by a 3.4.3 toolkit that was built with a 3.3.4 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 -mtune=pentium -fforce-addr -momit-leaf-frame-pointer -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.3, 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 -mtune=pentium -pipe" 

CXXFLAGS=${CFLAGS} 
```

7.2.2  Configuring the Default C Compiler

Although we have emerged GCC 3.4.3, 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.3 has already been ermerged, GCC 3.3.4 is still installed as out default compiler:

```
# gcc-config -l

[1] i386-pc-linux-gnu-3.3.4 *

[2] i386-pc-linux-gnu-3.4.3

[3] i386-pc-linux-gnu-3.4.3-hardened

[4] i386-pc-linux-gnu-3.4.3-hardenednopie

[5] i386-pc-linux-gnu-3.4.3-hardenednossp 
```

Change the default compiler to gcc 3.4.3 by issuing the following command:

```
# gcc-config 2
```

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.3 compiling toolkit (which had previuosly been compiled with GCC 3.3.4) with the GCC 3.4.3 compiler, taking advantage of our new USE flags and CFLAGS compiler settings.  

```
# emerge glibc binutils 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.3 and our hardware-specific settings.  

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

```
# emerge -e system  
```

7.2.5  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 -C linux-headers && emerge linux26-headers && emerge gcc-config glibc binutils gcc 
```

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

Step 3:

```
# gcc-config 2 && env-update && source /etc/profile && emerge glibc binutils gcc portage && emerge -e system 
```

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 udev 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-dev-sources
```

9.2  Building the Kernel Symlink

```
# rm /usr/src/linux

# cd /usr/src

# ln -s linux-2.6.10-gentoo-r2 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_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 
```

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.10-r2  

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.10-r2, 1024x768 

root (hd0,0) 

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

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

# Boot Gentoo Linux at 1280x1024 framebuffer resolution

title Gentoo-2.6.10-r2, 1280x1024 

root (hd0,0) 

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

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:
```

Have fun with your new Gentoo system!

12.  If You Should Encounter Problems

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 Stage 1 on 3 Support Thread in the Installing Gentoo forum.

At this time this Installation Guide has evolved to a fairly mature state, such that most problems that are likely to be encountered during an install are likely to be related to individual factors not attributable to the Installation Guide. It would seem fair if those who encountered problems with architecture specification, CFLAGS, etc. could post their requests for help in the appropriate support forums. (That way, once your personal support request is resolved, your problem will scroll off into oblivion instead of being preserved here forever, interspersed with this documentation.) 

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.

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

14.  Acknowledgements

Special thanks to kimchi_sg for his many comments that have helped to refine this Guide and for all of his help in the support thread.

Special thanks go to ali3nx for his helpful tutorial on building a Gentoo Stage 1 system using NPTL.  

Special thanks also go to rac for sharing with us the great idea of building Stage 1 Gentoo installations using a Stage 3 tarball.

Thanks to the following people who have contributed to my understanding of Gentoo and helped me solve problems as I was learning my way around:  hardcore, NeddySeagoon

The following people's comments on the Gentoo Forums on related threads have also contributed indirectly in the writing of this Installation Guide.  Their names are listed in alphabetical order:  heilvc, Hobbit-HK, irf2003, kimchi_sg, Oktane

My sincere apologies if I've left anyone out!

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

15.  Downloadable PDF Now Available

A copy of this Installation Guide is now available in PDF format.  Click Here.  Please note that it may not be updated as often as the on-line version of this guide.

16.  Revision History

01-05-05: Corrected typos, Added relaxed CFLAGS statements, Added PDF document

01-06-05: Corrected typos, Added sample /etc/make.conf, Added NUMLOCK toggle at Boot

01-08-05: Reordered Portage Config to follow Chroot, Added "Gentoo" Grub Splash Screen

01-09-05: Create non-Standard Portage Directories

01-12-05: Cleaned up redundant CFLAGS, Reverted to Stable Branch

01-17-05: PDF Synchronized with On-Line Installation Guide

01-19-05: Corrected typos

02-20-05: PDF Sync, grub.conf, adduser to wheel group, plug for hielvc/MindEraser emerge wrapper

02-23-05: Link added to Support Thread

03-08-05: Emerge ccache, Setterm -blank

03-22-05: Revised proc mounting

03-28-05: Fixed localhost IP address typos

04-01-05: Removed superfluous USE flags

----------

## /dev/random

In section 4.4.1 I think it should be fdisk /dev/hda instead of hdparm also if it's titled display partition information instead of create partitions then it really should be 

fdisk -l

Other than that good job man.

Edit: Also to stay consistent with the handbook I suggest putting the kernel section before section 7.3 but that's entirely up to you.

----------

## landon

ehe, you mentioned yourself in the list of acknowledgements.   :Laughing: 

----------

## Bob P

 *landon wrote:*   

> ehe, you mentioned yourself in the list of acknowledgements.  

 

hey, i really like that guy -- he helped ALOT!   :Wink: 

----------

## kimchi_sg

Bob: the cflags u put here are really too extreme. I'm afraid some n00b will use them and find that building of toolchain b0rks on "compiler cannot create c executables". Try toning them down a lot?  :Smile: 

----------

## Insanity5902

Bob - nice how-to, i was thinking of writing one just like it as this is how I installed my last server.

I think you shouldn't suggest using all those CFLAGS.  They are too extreme to be used in a How-To.  You should only suggest 

```
CFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -pipe"
```

anything more might cause more trouble then it is worth.

----------

## Bob P

 *Insanity5902 wrote:*   

> Bob - nice how-to, i was thinking of writing one just like it as this is how I installed my last server. 

 

Well,  its the way that i reconfigured my P3-800 desktop and set-up my P-133 that will soon be a router.  I figured that I might as well strike while the iron was hot, as if I hadn't written the tutorial sooner than later, somebody else might have beaten me to it.   :Wink: 

 *Insanity5902 wrote:*   

> I think you shouldn't suggest using all those CFLAGS. They are too extreme to be used in a How-To. 

 

Wow, I hadn't expected to take so much heat on the subject of CFLAGS.  I guess I have a couple of points to say about them:

First, there's really no point in upgrading from GCC 3.3 to GCC 3.4 if you're not going to take advandage of the performance enhancing features that are available in 3.4.  By upgrading to 3.4 and using the CFLAGS I've listed, you'll notice a significant performance increase on Intel architecture.  (I haven't tried it on anything else).  As others have noted in the GCC 3.4 thread, upgrading to 3.4.3, using these CFLAGS, and recompiling your system feels like you've had a hardware upgrade.  If you're trying to get state of the art performance out of your box (that's why we're here, isn't it?), you're really doing yourself a disservice by not using optimization level 3 and the CFLAGS listed in this tutorial.

Second, these CFLAGS are well-tested on Intel architecture and are very stable.  They've been tested by many people on Pentium, Pentium2, Pentium3 and Pentium4 systems without any problems.  In spite of the fact that they look imposing, they really are not as bad as they seem!  Experience has shown that they're indeed very safe ways to optimize your system.  In addition, some of them are only enabled at optimization level -O3, so backing down to -O2 may be advisable for those that encounter problems or just don't want to deal with extreme levels of code optimization.  But I think its only fair to mention that going from -O3 to -O2 and omitting some of those CFLAGS iis going to result in a tangible performance hit.

Third, its important to remember that by following this tutorial, the user is committing to the "~x86" branch, not "x86". We all know that "~x86" is not a branch for n00bs, so IMHO there's a limited amount of n00b friendliness that needs to be built into this tut.  If I were still a n00b (some might argue that I am  :Smile: ), I wouldn't think of a Stage 1 on 3 install as something reasonable to underake -- if you look at the Stage 1 NPTL thread, even the Gurus and L33ts missed some of the subtleties of performing the GCC upgrade in the Stage 1 on 3 context.  In all respects, we're pushing the envelope to the maximal extent possible while keeping the system stable.  For some people this approach may be over their heads.  If that's the case, maybe a more traditional installation following the guidelines in the Gentoo Installation Handbook is a better idea.  You know the saying: "If they can't run with the big dogs, they might as well stay on the porch."  (Sorry, I just couldn't resist!)

Finally, I didn't say that anyone had to use those CFLAGS -- I only recommended them as being worth considering.  I wouldn't have any objections if anyone decided to pare them down to the simpler set that you've recommended -- they just won't find their way onto my system because i'm trying to wring as much performance out of the code as possible.  After all, I'm pushing some old hardware as far as it will go, and my intent is to be merciless in that regard.  But following your suggestions, I think I'll upgrade the tutorial to mention a more conservative CFLAGS setting for those who aren't as gung-ho.

Thanks again for your compliments!  :Wink: 

----------

## Hauser

I've recently built a system with gcc-3.4.3 (mainly because I want to use the '-march=pentium-m' flag) for my new laptop, the performance turns out to be quite impressive; the system was initially built on my AMD desktop (and runs on it!  :Wink:  ), the laptop runs just as fast (pentium-m 725 1.6GHz) as the desktop system (actually the laptop feels a little bit faster for me, perhaps because it has 1G RAM!), even though my CFLAGS are pretty conservative ("-O2 -march=pentium-m -fomit-frame-pointer") 

Of course I also use nptl, linux26-headers, but I've only got a few ~x86 packages:

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

=sys-devel/gcc-3.4.3-r1

=sys-libs/libstdc++-v3-3.3.3-r1

=sys-kernel/nitro-sources-2.6.9-r3

=x11-terms/mrxvt-0.3.11

=app-office/openoffice-ximian-1.3.6

=media-libs/freetype-2.1.7

media-gfx/855resolution ~x86

media-video/ffmpeg ~x86
```

Besides, I built from stage1.  Before the bootstrap, I did (as far as I can remember):

```
# emerge --nodeps --oneshot linux26-headers

# USE="bootstrap" emerge --nodeps --oneshot gcc 
```

This one was emerged with p3 flag, after gcc-3.4.3 was installed , I changed the flag to p-m and started the bootstrapping process.

I did 'gcc-config -c' several times to make sure portage was using 3.4.3, the whole process turned out to be quite smooth, and I'm quite happy with the result.    :Very Happy: 

----------

## Hobbit_HK

IIRC, opensp (and now also gettext) won't compile with (some of) these CFLAGS.. I don't know which one caused it to die, but when I returned to the conservative flags, everything went smooth...

Also, -fvisibility-inlines-hidden and -fvisibility=hidden are only valid for C++, and should be in CXXFLAGS

EDIT: Well, well! As soon as I moved the C++ flags to CXXFLAGS gettext compiles! You should fix that in your CFLAGS section..

----------

## Insanity5902

Bob - I haven't read that much about the 3.4 cflags but according to what you said, you should pug a disclaimer that this is for the intel arch and that it might or might not cause problems.

There are a lot of threads around the forum now with the Devs saying they are going basically disregard all bugs with agressive cflags.  They say if you want to get help you will have to recompile your program with the basic flags see if the problem still exists and then post a bug on it.

I didn't mention this up there but great article.

----------

## Bob P

 *Hobbit_HK wrote:*   

> EDIT: Well, well! As soon as I moved the C++ flags to CXXFLAGS gettext compiles! You should fix that in your CFLAGS section..

 

most of those CFLAGS were stolen from irf2003's contribution to the GCC thread.   :Wink:  *irf2003 wrote:*   

> 
> 
> ```
> 
> CFLAGS="-O2 -mtune=pentium4 -march=pentium4 -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -frename-registers -fweb -ftracer -pipe "
> ...

 

my typing skills being what they are, i managed to get the cflags right on my testbed PC, but i mistyped them into the tutorial.  D'Oh!   :Embarassed:   Thanks for pointing out the error.  

BTW, I'm happy to hear that putting these 'aggressive' CFLAGS into your make.conf solved some of your problems.   :Cool:   ... and thanks for putting a link to this tutorial in your tag line!  :Shocked: 

----------

## hielvc

Ok Bob_Ping on my parade  :Laughing:   nice Howto.  But I agree with kimchi_sg ( tell em to go put solved on rac's thread, that should slow him down some  :Wink:  ) about the CFLAGS. But thats for people to try and see what makes them happy. My 2 cents the fewer the better and on a serious note my first year and a half useing  Gentoo was on a P166 and after doing the CFLAGS shuffel many times what I finally ended up wtih was "-march=pentium -Os -pipe".  It built faster and was diffently quicker loading X and useing X apps.

----------

## Bob P

 *Insanity5902 wrote:*   

> There are a lot of threads around the forum now with the Devs saying they are going basically disregard all bugs with agressive cflags.  They say if you want to get help you will have to recompile your program with the basic flags see if the problem still exists and then post a bug on it.

 

this reminds me of a post by robmoss in the sticky GCC thread.  Is that what you're referring to?  I got the impression that the issue was about "x86" vs. "~x86" and "arch" vs. "~arch", not about compiler flags:

 *robmoss wrote:*   

> <rant> For all those whinging about how this broke their box - I don't care. ~arch is for testing ebuilds, not packages. If you want an ebuild that we know works, use arch. If that doesn't work, complain! But if a ~arch ebuild doesn't work - for example, the gcc-3.4.3 ebuild screwing up the libtool stuff and gcc-config not running as it should have done - then file a bug. Don't whinge. Don't say you're leaving. You know what the risks are of running the testing tree is - instability. The packages themselves will be stable, but the ebuilds will not. That's what happened - the ebuild was still meant to be tested by people other than the one developer who'd had the chance to use it, and was himself only upgrading from one gcc-3.4.3 snapshot to another one, meaning he hadn't come across the bugs mentioned. </rant>

 

regarding the CFLAGS i've used here, robmoss actually called them "quite conservative."  in my limited experience they shouldn't cause problems, but i agree they may not be for everyone.  i've updated the tutorial to list some very basic CFLAGS as an alternative option.

----------

## kimchi_sg

Bob: I stand corrected on the aggressiveness of these cflags.  :Smile: 

Just a little correction to the amended CXXFLAGS... there should be a space after the curly bracket that ends the CFLAGS, and before the - that starts -fvisibility-inlines-hidden. Otherwise -fvisibility-inlines-hidden will be tacked onto the last CFLAGS option as one word.  :Sad: 

EDIT: How about putting this one on the gentoo wiki as well?

EDIT 2: You mentioned the command to add ntp-client to the default runlevel as 'ntp-client default'... obvious omission?

----------

## seringen

I'm just wondering if people are actually ok with running hotplug and coldplug in the default runlevel.  I've found that I've had to load them as boot runlevels as a way to actually get hal to work properly in my udev only system.

e.g. rc-update add coldplug boot #instead of default

am I really the only one with that problem/

p.s. 7.3.3 shouldn't read 

```
ntp-client default &&
```

 assuming people follow your advice above.  Plus a lot of the things you take from the other list are only for servers.  does a normal person really need to be running xinetd?

p.p.s. 8.3.1 should be 

```
/etc/conf.d/[b]rc[/b]
```

p.p.p.s. 9.6 should be 

```
rc-update [b]add[/b] hdparm boot

```

hthLast edited by seringen on Thu Jan 06, 2005 1:57 am; edited 1 time in total

----------

## Bob P

 *kimchi_sg wrote:*   

> EDIT: How about putting this one on the gentoo wiki as well?

 

a Wiki?  sure, that would be a great idea.  but before i do that, i'd like to stomp out all of the little typos and bugs that have found their way into the document, and i'd like to get a few more installations under my belt to work out any kinks that may remain in the system.  in the interim, i've posted the document as a print-optimized PDF.  this should make it easier for people who need a hard copy during installation.

You can download it HERE.

(Note: it may not be updated as often as this tutorial.)

thanks everyone, for pointing out typos and such!

----------

## Insanity5902

This is a very nice tut.  I think it has came together quite well.  I have been thinking about rebuilding my desktop machine.  I might print off the pdf you have and follow it word by word to see how it turns out.

(my desktop needs to be cleaned off, this was my first gentoo install and I was still naive on the ways of portage.  I like the way I have my laptop set up, using x86 and only doing ~x86 for specific apps instead of a pure ~x86 and a couple of hard-masked apps  :Razz: )

----------

## Hobbit_HK

Am I the only one failing to compile opensp with these CFLAGS? I hope I can work this out somehow.. I don't want to emerge opensp seperately with conservative flags and leave it out on every emerge -e (system|world)...

----------

## deXtuX

When emerging media-libs/id3lib-3.8.3-r3, I got unsigned char* errors which resulted in a failed compile.  I was using the following cflags/cxxflags (i.e the ones suggested above):

CFLAGS="-O3 -mtune=pentium4 -march=pentium4 -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -frename-registers -fweb -ftracer -pipe"

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

(and gcc 3.4.3 r1)

I tried removing  -fvisibility=hidden from the CXXFLAGS line and it emerged sucessfully.  

Anyway, once emerge -e world is done ill try doing it again and seeing if I can post the exact error message, since I 'cleverly' managed to loose it after closing the console and overwriting the log.

----------

## Hobbit_HK

LOL.. You need to be really good at your work to do BOTH things..  :Wink: 

I would post the error message, but it's several pages long... It kinda repeats itself though.. 

```

: undefined reference to `OpenSP::Allocator::free(void*)'

RastEventHandler.o(.gnu.linkonce.t._ZN6OpenSP21EventHandlerMessengerD1Ev+0x13):

In function `OpenSP::EventHandlerMessenger::~EventHandlerMessenger()':

: undefined reference to `OpenSP::Messenger::~Messenger()'

RastEventHandler.o(.gnu.linkonce.t._ZN6OpenSP21EventHandlerMessengerD0Ev+0x14):

In function `OpenSP::EventHandlerMessenger::~EventHandlerMessenger()':

: undefined reference to `OpenSP::Messenger::~Messenger()'

RastEventHandler.o(.gnu.linkonce.t._ZN6OpenSP10LinkRulePiD1Ev+0x2b): In function

 `OpenSP::LinkRulePi::~LinkRulePi()':

: undefined reference to `OpenSP::Link::~Link()'

RastEventHandler.o(.gnu.linkonce.t._ZN6OpenSP10LinkRulePiD1Ev+0x46): In function

 `OpenSP::LinkRulePi::~LinkRulePi()':

: undefined reference to `OpenSP::Link::~Link()'

RastEventHandler.o(.gnu.linkonce.t._ZN6OpenSP1

```

And so on and so forth (just with changed functions names)..

EDIT: Ok.. Removing the visibility CXXFLAGS helps.. weird

EDIT2: Ok... -fvisibility=hidden is the problem here... I'll recompile my system w/o it then...

----------

## hielvc

Bob you should add a step somewhere after you untar the stage3 tartball. A good place would be while people are editing thier /etc/make.conf. To get a complete listing of all your emerges, no more lost errors logs you do this. 

```

# PORT_LOGDIR is the location where portage will store all the logs it

#     creates from each individual merge. They are stored as YYMMDD-$PF.log

#     in the directory specified. This is disabled until you enable it by

#     providing a directory. Permissions will be modified as needed IF the

#     directory exists, otherwise logging will be disabled.

PORT_LOGDIR=/var/log/portage so to add it

echo "PORT_LOGDIR=/var/log/portage" >> /etc/make.conf

mkdir /var/log/portage
```

This a copy of what you see on the screen as something emerges.

EDIT wheres Thursday Next when you need her to gather up all these words and letters that keep escaping

----------

## Bob P

thanks to you brave souls who have been testing the tut on your hardware.  i haven't had the problems with the CFLAGS on my Pentium or Pentium 3 testbeds, so i wonder if this may be architecture specific.  what architecture are you guys running?  at any rate, it seems that the problems are consistent enough that i'm going to remove  "-fvisibility=hidden" from the CXXFLAGS.

heilvc, thanks for the recommendation about make.conf.  i know that i haven't posted any recommendations for make.conf yet, and failure to set it up optimally may be causing problems for people with less experience.  in my make conf, i have all of those portage directory options set and the logging directory created, but you're right -- these settings should be added to the guide.  

i've hesitated to post my make.conf file, though, as i normally use the "userprivs usersandbox" in FEATURES so that portage doesn't run as root.  the problem with doing this, though, is that there are plenty of broken ebuilds right now that generate dyn_test errors because of faulty handling of file privileges.  the workaround, at present, is to remove "userprivs usersandbox" from FEATURES, but i consider that bad practice and hard to recommend.  its sort of a Catch-22.  its bad form to leave those features out, but until the ebuild bugs are squashed you have to do it for the broken ebuilds to compile.  i'm going to bite the bullet and  post a sample make.conf and add the step for creating the logging directory.  thanks.

----------

## fbeauregard

I think there is a typo at step 6.6

The use flag userlocales is ok (therefore the content of /etc/portage/package.use is ok) but the file should be /etc/locales.build

Cheers,

François

----------

## Hobbit_HK

Yeah I noticed that too...

And does anybody else have a problem compiling xorg-6.8.1?

----------

## fbeauregard

I just noticed that http://gentoo-wiki.com/NPTL suggest the nptl and the nptlonly use flags. The howto only suggest nptl. Was this on purpose or an omission?

Cheers,

François

----------

## Bob P

 *fbeauregard wrote:*   

> I just noticed that http://gentoo-wiki.com/NPTL suggest the nptl and the nptlonly use flags. The howto only suggest nptl. Was this on purpose or an omission?

 

the answer to this question is so important that i'm going to put it in boldface type:

it was done on purpose.  if you add "nptlonly" glibc will compile once (and only once) with NTPL support.  if you don't specify "nptlonly" then glibc will compile twice, once providing NPTL support, and again to provide fallback support for linuxthreads (pthreading).  notice the pthreads USE flag.

if you specify nptlonly, you are taking away your safety net and undermining the "bulletproof" feature of this installation method.  if you do that, you'll find that there are plenty of programs out there that may bork on you.  proceed at your own risk.

Hobbit -- in regard to those CXXFLAGS settings -- i've just finished another Intel-based system installation with both sets of CXXFLAGS without any problems whatsoever.  

are you guys who've had the CXXFLAGS problems using a non-Intel platform?   or maybe different make.conf settings?  as far as i can tell, the CXXFLAGS statements are working great on Intel systems that are using my make.conf settings.  if you're having problems, please send me a PM and tell me what's going on.  if i need to update the tut for specific architectures, i'd be happy to do that.  in the interim, i'd like to know why you guys are having problems that you shouldn't be having.

----------

## hielvc

If you can solve it the Developers would love to know. Its why the Dev usually are posting "-march=ARCH -O2 -pipe" as the besat bet and are what most of them use when they build and test. There are just to many variables involved with different mobo bios's drives video and agp. The biggest boost that you get with gentoo is with your CHOST and "-march=" settings the rest might add 5% and that is only going to be for certian progs. Whats good for one will be ignored by another and harmfull for the third. Remeber computers are general purpose machines and some work better than others  :Wink: 

----------

## deXtuX

 *Bob P wrote:*   

> 
> 
> Hobbit -- in regard to those CXXFLAGS settings -- i've just finished another Intel-based system installation with both sets of CXXFLAGS without any problems whatsoever.  
> 
> are you guys who've had the CXXFLAGS problems using a non-Intel platform?   or maybe different make.conf settings?  as far as i can tell, the CXXFLAGS statements are working great on Intel systems that are using my make.conf settings.  if you're having problems, please send me a PM and tell me what's going on.  if i need to update the tut for specific architectures, i'd be happy to do that.  in the interim, i'd like to know why you guys are having problems that you shouldn't be having.

 

No, on an Intel platform; I am actually using a Pentium 4, my make.conf settings were as follows:

CFLAGS="-O3 -mtune=pentium4 -march=pentium4 -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -frename-registers -fweb -ftracer -pipe"

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

Everything emerged perfectly except for that one program, media-libs/id3lib, which would only seem to compile once I took out "-fvisibility=hidden".

----------

## Bob P

 *hielvc wrote:*   

> If you can solve it the Developers would love to know. 

 

hehe.  you make a good point there.  just because the stuff works on my testbed platforms (which are all intel mobos with intel chipsets and very boring PCI Matrox video systems) doesn't mean much about the luck that anyone else might have.  i'll be the first to agree, if you have aggressive USE flags and CFLAGS and you have compile problems, then look at the obvious sources.  if you should get a CFLAGS related error message popping up, listen to what the computer's telling you and forget about what i've been doing on my PCs.    :Wink: 

btw, nice to see that you;re a Veteran now.    :Cool: 

----------

## Bob P

 *deXtuX wrote:*   

> CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden -fvisibility=hidden"
> 
> Everything emerged perfectly except for that one program, media-libs/id3lib, which would only seem to compile once I took out "-fvisibility=hidden".

 

you know, if you've got firm and accurate data about what CXXFLAGS settings break an e-build, be sure to file a bug report on it at https://bugs.gentoo.org !  developers are very happy to hear detailed and accurate reports about specific compiler settings that cause their programs to break.  it may lead them to identify a problem in their code that needs to be fixed.

for all of you guys that have had CFLAGS related problems, please file a bug report on bugzilla so the developers know exactly what causes their program to break, and what steps will fix it.

----------

## hielvc

Your right. I ig a vattren.  :Laughing:   I thought of petitioning the Muderators to become  a honorary l33t since I kant spill or type and in 1 post I managed to look like I was stutttttttering.

Now lets see 1-6-05 minus 4-19-02  is ..........Hummm Im not near as prolific you or Kimcihi_sg. You know ya shouldnt take speed, but then I shouldnt take downers  :Laughing: 

----------

## deXtuX

 *Bob P wrote:*   

> 
> 
> for all of you guys that have had CFLAGS related problems, please file a bug report on bugzilla so the developers know exactly what causes their program to break, and what steps will fix it.

 

Ok, compiled id3libs again with -fvisibility=hidden and it failed again, I did as you said and have filed a bug report here: https://bugs.gentoo.org/show_bug.cgi?id=77001

It's my first bugreport to bugs.gentoo.org, so I might have screwed something up in the reporting, though.

----------

## Hobbit_HK

Ok.. A quick search in bugzilla told me that I need to recompile linux26-headers and glibc and then xorg will compile successfully... Just wanted to let you know, if anyone else had this problem.

And here's my bug report for the opensp issue: https://bugs.gentoo.org/show_bug.cgi?id=77033

----------

## Bob P

 *Hobbit_HK wrote:*   

> Ok.. A quick search in bugzilla told me that I need to recompile linux26-headers and glibc and then xorg will compile successfully... Just wanted to let you know, if anyone else had this problem.
> 
> And here's my bug report for the opensp issue: https://bugs.gentoo.org/show_bug.cgi?id=77033

 

that's interesting -- since you started your Stage 1 project using the ali3nx method before i posted the tutorial, and jumped into this tut mid-stream in your install, i'd like to ask a question about your linux26-headers and glibc:  did you emerge your linux26-headers and glibc using the --oneshot option, like suggested in some of those other threads?  or did you omit the --oneshot option, like i've suggested in this tut?

fwiw, on my installs (and in the tut), i didn't use the --oneshot option.  the upside to this is that the programs emerged without --oneshot get added to the world file and get re-emerged to further nail-down the toolchain on the subsequent emerge -e system.   the downside to  this is that the programs emerged without --oneshot get added to the world file and get re-emerged on any subsequent emerge -e system.   :Very Happy: 

this tut specifically mentions this extra pass on the headers and glibc as being necessary.  i've never seen this "redundant" step in another tut.  since you were working from two differnet tuts, could you have skipped this step by any chance? i'm wondering if that could have been the source of your problems.  if that turns out to be the case, you've provided a very helpful diagnostic test of a theory that i had incorporated into the tutorial that had never been tested.    :Idea: 

back to the --oneshot issue:  i'm wondering if my extra emerge of those files when nailing down the toolchain prevents the bork that your ran into with xorg...  maybe i've stumbled onto something!  :Very Happy: 

i have to admit that i am not thrilled about the idea of having the toolchain monkeyed with every time that one performs a subsequent emerge -e world.  after nailing down the toolchain in our system build, it may be best to prevent future unintentional modifications by portage.  i'd been thinking about adding a step where the toolchain gets masked in portage.  has anybody thought about that?

the other option would be to use --oneshots in the tut, but add a section that repeats the --oneshots before doing the emerge -e system.  that way we'd get the necessary redundant emerges while keeping the toolkit out of the world file.

through all of your great posts on the other threads, you gurus, l33ts and veterans have helped to develop this tutorial, so now i'm going to ask for your opinions -- what do you think?

----------

## Bob P

 *deXtuX wrote:*   

> Ok, compiled id3libs again with -fvisibility=hidden and it failed again, I did as you said and have filed a bug report here: https://bugs.gentoo.org/show_bug.cgi?id=77001
> 
> It's my first bugreport to bugs.gentoo.org, so I might have screwed something up in the reporting, though.

 

That's a good bug report.  If i were a developer, I'd appreciate a report like that one.  Ulike most bug reports that just say, "Your program is broken, please fix it," your bug report tells them exactly what breaks the program and exactly what steps will fix it.  That kind of complete report is very helpful, as it itentifies the nature of the problem.  Its the kind of report that I would like to see if a problem like that happened with one of my programs.  I wish all bug reports contained that much useful information.   :Wink: 

----------

## Hobbit_HK

 *Bob P wrote:*   

> 
> 
>   did you emerge your linux26-headers and glibc using the --oneshot option, like suggested in some of those other threads?  or did you omit the --oneshot option, like i've suggested in this tut?

 

Nope, I did:

```
emerge --oneshot --nodeps gcc-config && emerge -C linux-headers && emerge linux26-headers &&  emerge glibc portage binutils gcc
```

And after editing make.conf I did:

```
emerge glibc binutils gcc && emerge -e system && emerge -e system
```

 *Bob P wrote:*   

> 
> 
> i have to admit that i am not thrilled about the idea of having the toolchain monkeyed with every time that one performs a subsequent emerge -e world.  after nailing down the toolchain in our system build, it may be best to prevent future unintentional modifications by portage.  i'd been thinking about adding a step where the toolchain gets masked in portage.  has anybody thought about that?
> 
> 

 

That seems like a very good idea...

----------

## hielvc

As I remeber when I first started useing linux26-headers the recomendation was 

```
 emerge -C linux-headers && emerge linux26-headers glibc && emerge --oneshot glibc binutils && emerge gcc binutils 
```

 It was recommended to build glibc twice. The first to build against the new headers and to second to make sure that it was installed without any contamination from old headers.

----------

## Bob P

 *hielvc wrote:*   

> As I remeber when I first started useing linux26-headers the recomendation was 
> 
> ```
>  emerge -C linux-headers && emerge linux26-headers glibc && emerge --oneshot glibc binutils && emerge gcc binutils 
> ```
> ...

 

right, the double compilation makes perfect sense to me.  that's why those packages get built in section 7.1 and rebuilt in section 7.2.4 of this tut.  :Wink: 

now that i've got your attention, let me as a question about the code listing you posted:  what is the point of the "--oneshot" when emerging glibc the second time?  the first time glibc is emerged it is emerged without "--oneshot", so using "--oneshot" on the second emerge doesn't make sense to me.  also, binutils is subsequently emerged without "--oneshot".  together, these three steps totally negate the effect of "--oneshot" in "emerge --oneshot glibc binutils", don't they?

the reason that i ask about this is because i would like to alter the tut so that the toolkit is emerged with --oneshots, so that an "emerge -u world" doesn't inadvertently bork a stable toolkit.  the problem seems to be that as soon as you do an "emerge -uD world" some of the toolkit components are going to be re-emerged as dependencies, whether you like it or not.  i think that the only way to prevent this is to RSYNC_EXCLUDEFROM those packages so that when doing an emerge --sync portage never sees them.  

what do you think?  i know that in some respects its impossible to idiot-proof a system, but i would like to configure the set-up so that regular maintenance doesn't corrupt the toolkit.

----------

## thecookie

Hi!

First off, thanks for a sweet guide! I have been reading alot of the Stage 1-3 NPTL installs on these forums and on gentoo-wiki.com. I ended up here - using this guide to install my frist gentoo system. I am using your sample make.conf file and all your settings.

I have a little question about emerging the linux26-headers:

```
emerge -C linux-headers && emerge linux26-headers glibc && emerge --oneshot glibc binutils && emerge gcc binutils
```

I get the result (I had already run it once, therefore it couldn't find linux-headers):

```
livecd / # env-update && source /etc/profile && emerge -C linux-headers && emerge linux26-headers && emerge gcc-config glibc binutils gcc

>>> Regenerating /etc/ld.so.cache...

 * Caching service dependencies...

--- Couldn't find linux-headers to unmerge.

>>> unmerge: No packages selected for removal.

Calculating dependencies ...done!

>>> emerge (1 of 1) sys-kernel/linux26-headers-2.6.8.1-r2 to /
```

Should it really be emerging linux26-headers-2.6.8.1-r2? That isn't the latest?

Another issue I had was in section 6.2.2 in the guide:

 *Quote:*   

> 
> 
> 6.6.2 Update the Portage Tree
> 
> Update our portage snapshot to include the current portage tree. 
> ...

 

portage complained that /usr/local/portage didn't exist (set in make.conf, PORTDIR_OVERLAY=/usr/local/portage).

I am new to this, so any comments to clairify is appriciated!

Thanks.

----------

## seringen

 *Quote:*   

> 
> 
> portage complained that /usr/local/portage didn't exist (set in make.conf, PORTDIR_OVERLAY=/usr/local/portage).
> 
> I am new to this, so any comments to clairify is appriciated!
> ...

 

```
mkdir /user/local/portage
```

.  Lots of people ask that question, you should search for it next time  :Wink: 

Also, really this shouldn't turn into a big discussion of cflags, there's loads of threads for that.  And if you get a compilation error, SEARCH THE THREADS if you have compilation errors.  this is purely an installation methodology that works well, but it's not foolproof across time and space!

Anyway, It'd be great to get this up on the wiki, I'd do it myself, but I wanted to wait for the original author to ok it.  I was going to write my own almost exactly the same until i noticed someone else had done the hard work  :Smile: 

P.S.  I think we should leave NPTLONLY out of it, since it can break things, and people will come up with weird errors and blame the guide instead of them not knowing what they are doing *shrug*

----------

## thecookie

 *seringen wrote:*   

> 
> 
> ```
> mkdir /user/local/portage
> ```
> ...

 

It wasn't a problem, I did just that. It was just a note to the author, to maybe add it to the guide  :Smile: 

----------

## Bob P

 *thecookie wrote:*   

> I have a little question about emerging the linux26-headers:
> 
> ```
> emerge -C linux-headers && emerge linux26-headers glibc && emerge --oneshot glibc binutils && emerge gcc binutils
> ```
> ...

 

that sequence of commands isn't part of the tutorial, so i really don't understand why you would choose to intersperse it with the commands that are in the tutorial.  if you make changes to the tutorial, you should expect that the ultimate outcome may be different than if you had not.

 *Quote:*   

> I get the result (I had already run it once, therefore it couldn't find linux-headers):
> 
> ```
> livecd / # env-update && source /etc/profile && emerge -C linux-headers && emerge linux26-headers && emerge gcc-config glibc binutils gcc
> 
> ...

 

there are two ways not to find linux-headers on your system.  one way is to extract a Stage 1 tarball that doesn't contain linux headers.  the other is to remove them by issuing the emerge -C command.  if you emerge -C them, then they aren't there on subsequent attempts to emerge them.  so it seems that you had to deviate from the tutorial to get these results.

in order to keep this thread from evolving into a general support thread on how to install gentoo, please stick to the methods listed in the tutorial.  i'm more than happy to try to help if you can find a problem in the tut, but if you're going to install gentoo using a different installation method, your support questions should really go into one of the support forums, not here.  

the same should be said for the other guys who have KDE related questions.  they don't really belong here.  this is a thread about installing Gentoo, not installing KDE.  in addition to the fact that there is a Dekstop forum for KDE-type questions, this is a Documentation forum, not a support forum.  support questions don't belong here.

to answer your question about the syntax of the emerge commands, you are best NOT to specfiy the version number.  if you specify the version number, you will get what you ask for.  if you don't specify the version number, portage will give you the latest version in the portage tree.  there is good information about this in the Gentoo Installation Handbook.

 *Quote:*   

> Another issue I had was in section 6.2.2 in the guide:
> 
>  *Quote:*   
> 
> 6.6.2 Update the Portage Tree
> ...

 

if the directory /usr/local/portage does not exist, just create it by issuing the following command:

```
# mkdir /usr/local/portage
```

thanks for pointing that out.  i added some information about creating portage directories to the tut yesterday, and i might have missed something.

----------

## Bob P

 *seringen wrote:*   

> Anyway, It'd be great to get this up on the wiki, I'd do it myself, but I wanted to wait for the original author to ok it.  I was going to write my own almost exactly the same until i noticed someone else had done the hard work 

 

ultimately, i'd like to get it up on the Wiki, too.  but right now i'm still correcting little typos and such that are still present in the tut.  right now i'm maintaining this tutorial, as well as a PDF revision.  i'd like to give the tutorial enough time to mature into a document that i don't have to keep revising before i add it to the Wiki.  if i'm going to maintain 3 documents, i'd rather have them be finished rather than in a state of transition.     :Wink: 

----------

## hielvc

Bob I ran in to a portage upgrade prob yesterday. I went up to linx26-headers-2.6.8.1-r2. In and of its self this is not necessarily a reason to rebuild your tool chain or do 

```
emerge linux26-headers glibc && emerge glibc binutils gcc && emerge binutils gcc && emerge world -e 
```

Why because in theory 2.6 headers are a superset of 2.4 headers and /or of the oldier linux26 headers. So if you dont need the new features in the  new header set theres no obvious reason to rebuild the toolchain. In most cases and most of the time this is true, the problem being "most". I ran for 2 years just doing "emerge world -UDp" and then came across  emerge -U world - How often which lead to to 

```
 emerge  world -uDp
```

. the " -U " caused more probs than anything else. Most users of gentoo dont run " ~ARCH " and only occasionlly sync and update. They are  users who probably learned more about linux than they really wanted to when they installed. Their like construction workers, they use a hammer but they dont worship it. We on the other hand worship our computers and the operating system. Worship defined by what you spend most your time doing, for me, when I post, its the damn dictionary  :Wink: 

Anyway to get back on subject I could have just continued my world update with out any problems more than likely. But I was also considering your question. There are two times when you need to nail down your toolchain. The first is when you install your system and the secaond when your in a testing mode like robmoss. Most of us who run ~ARCH and hang around the forums and sync and update quite often fall inbetween. The other consideration in this is portage.  *Quote:*   

>  emerge system -ep
> 
> Calculating system dependencies   ...done!
> 
> [ebuild  N    ] sys-devel/patch-2.5.9-r1  
> ...

  doesnt exactly build in the order that I think it should. From above its binutils, gcc, libstdc++, linux26-headers, glibc which is halfway ass backwards. The order should be linux-headers, glibc, binutils, gcc, libstdc++.  This is why robs method is correct though a pain. 1st time through emerge system builds linu-headers then glibc, 2nd time through linux-headers and glibc nailing down glibc. Then rob does emerge world -e twice building binutils and gcc against twice built glibc giving you your basic stable toolchain and then emerges everything else with the stable toolchain.  Talk about a haveing a house built by the Three Stoges. Does this cause probs yes. Lots of them, probably not. The only time this would become supect is if you update linux-headers possibly and more likely when you upgrade glibc. Unless portage is changed this will be a continueing problem. There is a way to deal with it but you have to do it manually. 

My low tech method is to emerge system or world to a list and scan for glibc or header updates. If I find them edit the list takeing them out and run the toolchain emerge thingy, see above. Then run the list into a for loop useing the edited list, haveing removed linux-headers, glibc, binutils, and gcc . 

```
emerge world -uDp>wrld.lst

grep -i liunx26 wrld.lst 

grep -i glibc wrld.lst

   -----if yes----- 

emerge linux26-headers glibc && emerge glibc binutils gcc && emerge binutils gcc 

   

---to clean your file ----

cut -f2 -d "]" -s wrld.lst |cut -f1 -d "[">wrld1.lst

   ----edit out linux-headers, glibc, binutils,gcc----

nano wrld.lst

for i in $(cat wrld1.lst); do emerge --oneshot  =$i || echo $i>> failed.lst;done

```

```
for emerge sysrem/world -e

emerge world -ep | cut -f2 -d "]" -s >wrld.lst

-----no need to test as -e rebuilds everything including your toolchain ---

-----remove linux26-headers, glibc,binutils, gcc-------------

nano wrld.lst     

for i in $(cat wrld1.lst); do emerge --oneshot  =$i || echo $i>> failed.lst;done

```

This takes the least time and wouldnt be hard to automate, but its still an extra step and in someone like rob's case you would use emerge -e to generate your build list. How critical is this.....How fast is your system? I would recommend once a year or every 6months for most people and that might be overkill. For us eeeeh ohuuuma cron job once or twice a month? WHen things start breaking?   

Oh your question about gcc.It bootstraps itself when ever its built. That means that it builds itself 1st with orignal gcc-old then builds gcc-new.1 and uses gcc-new.1 to build gcc-new.2 and then compares the three. The actual comparision Im not clear on as to if its a md5sum or what..

EDIT fixed run away words. Updated logic and build order in toolchain thingy. Added 2 update methods to manually update as the listing output of emerge -uDp and -ep are slightly different.

----------

## hielvc

I also ran 

```
 emerge linu26-headers glibc && glibc binutils gcc
```

 It didnt put them into my world file so theres is no reason to use --oneshot here. Also I ran the above because I think it might bemore correct. Why build binutils and gcc until glibc is cleanly installed? If this logic is correct then 

```
emerge linu26-headers glibc && glibc binutils gcc && emerge binutils gcc
```

 would probably be the correct form.

In my previous post about the "for loop" --oneshot is needed because you are emergeing one package at a time manually and that would enter all of them into your world file.

----------

## Bob P

 *hielvc wrote:*   

> I also ran 
> 
> ```
>  emerge linux26-headers glibc && glibc binutils gcc
> ```
> ...

 

i think you've got a typo there.  did you mean to type this?

```
 emerge linux26-headers glibc && emerge glibc binutils gcc
```

 *hielvc wrote:*   

>  It didnt put them into my world file so theres is no reason to use --oneshot here.

 

yeah, unlike typical "world" programs, the basic toolkit components don't appear to get added to the world file, regardless of whether or not you use the --oneshot command line argument when you do your emerge. so i've been leaving it out.

even so, when you do an emerge -uD world, you're going to find that those toolkit components find their way into the emerge list because of the "D" parameter.

personally, i'd like to NOT have toolkit components become emerged as part of a world update.  i'd prefer not to have my toolkit monkeyed with just because i'm trying to update packages in my world file.  for this reason,  i don't like to do world updates.  portage ends up giving you stuff that you don't really want (or need).

optimally, i would like to freeze the package versions for all of my toolkit components in portage.  i tried doing this with package.mask, but the results weren't working as well as i had expected.  instead of getting [ebuild R] i am always getting [ebuild UD] output.

i have also tried experimenting with RSYNC_EXCLUDEFROM, but I don't have the syntax right yet.  optimally, i'd like to exclude my toolkit from any upgrade that isn't specifically intended to modify the toolkit.  package masking didn't seem to work, so it seems that excluding from RSYNC may be the only way to keep the packages from showing up in the portage tree.  i'm still having trouble with the syntax though.

----------

## Bob P

 *hielvc wrote:*   

> ... doesnt exactly build in the order that I think it should. From above its binutils, gcc, libstdc++, linux26-headers, glibc which is halfway ass backwards. The order should be linux-headers, glibc, binutils, gcc, libstdc++.  This is why robs method is correct though a pain. 1st time through emerge system builds linu-headers then glibc, 2nd time through linux-headers and glibc nailing down glibc. Then rob does emerge world -e twice building binutils and gcc against twice built glibc giving you your basic stable toolchain and then emerges everything else with the stable toolchain.  Talk about a haveing a house built by the Three Stoges. Does this cause probs yes. Lots of them, probably not. The only time this would become supect is if you update linux-headers possibly and more likely when you upgrade glibc. Unless portage is changed this will be a continueing problem. There is a way to deal with it but you have to do it manually. 

 

yes, i have to agree with your assessment that portage itself is really quite stupid about how it goes about doing things.  i remember reading in one of robmoss' posts that portage has absolutely no clue on the order in which its supposed to emerge things, and looking at the output of a proposed emerge, i'd have to agree that he is right. 

instead of building the system rationally (the way we like to do it), portage does it very stupidly.  it doesn't do things in the order in which it should, and because of that you have to perform multiple, multiple emerges to get the job done right.  i think that this is where robmoss' idea of emerge -e system x2 and emerge -e world x 2 comes into play. 

because portage is stupid (doesn't bother to compile things in the proper order), he relies on a brute force approach to compile everything redundantly.  sure, the brute force method works, but you waste an awful lot of time recompiling stuff that doesn't need to be recompiled.  but by recompiling everything redundantly, you're sure to hit everything that needs to be recompiled.  it would sure make alot more sense to do only what you need to do, and to do what you need to do in the right order.  that's where the bootstrap scripts come into play on a Stage 1, and that's where our toolkit build/rebuild methodology comes into play on a Stage 1 on 3.  

IMHO, the brute force approach is a poorly designed approach.  Gentoo would be a much better system if portage used common sense in the order in which it emerges things.  right now, i think that our ordered approach of build the toolkit, rebuild the toolkit, and emerge -e system beats the robmoss method hands-down. it takes a little more typing, but it eliminates alot of the CPU cycles that are wasted on recompiling things that don't need to be recompiled.

i think you're right -- only hardcore idiots  :Wink:  like us would perform the upgrade ritual time and time again.  the amount of compile time amounts to a huge waste in computing power, and you really need to have an extra computer at your disposal to really enjoy using Gentoo.  the fact that the process of rebuilding a system is so clusterborked (did i just coin a term?  :Idea: ), and the fact that it takes your hardware down for such a long time is one of the things that stands in the way of making Gentoo more appealing to a wider group of people.

for the time being, i'd be happy if i could find a reliable way of keeping linux26-headers, glibc, binutils and gcc out of the portage tree when updates are proposed.

----------

## hielvc

Well the only 2 real culprits that can mess up the toolchain are linux-headers and glibc. I saw in a post yesterday that either tk or tcl is haveing probs emergeing. The fix in the bug report is re-emerge linux-headers glibc again and then it builds fine  :Laughing:  If your toolcahin is clean then updateing binutils or gcc wont hurt unless they're broken ebuilds. Then your clusterborked. That why I build packages. Wtih them I can downgrade easily even after portage dies,as long as tar is working. That has saved me a couple of times.

Me mistype or have them nasty words run off the page, never.  :Embarassed: 

----------

## caravela

the CXXFLAG -fvisibility=hidden  makes several packages fail to compile or linking.

fam,openslp,some kde pacakges (arts ,kdelibs,...)

----------

## kimchi_sg

Last edit to this post (31 Mar 2005) : Insane CFLAGS used to be featured here. However, being more mature in my Gentoo usage I have come to realise that some of these flags are probably more harmful than advantageous. Thus they are removed.

USE THESE CFLAGS AT YOUR OWN RISK

Everybody's talking about which is the safest set of CFLAGS to carry them through emerge system. I however, have used some less-than-conservative CFLAGS (borrowed from some kind chap on #gentoo  :Very Happy: ) and these have survived the course of this installation tutorial, even when merged with Bob's "conservative" set.

Note that the reference processor architecture here is that of ATHLON-XP. This will work for AMD Sempron processor too.

Disclaimer: I am NOT responsible for any loss of data, time or life caused by any failed emerges resulting from the usage of these CFLAGS. I have not used these CFLAGS for any emerge at all, other than for installing according to Bob P's instructions in the first post of this topic (up to and including "emerge splashutils").

You can safely suspect that CFLAGS are the cause of your aborted emerges if, for example, the emerge aborts during the compiler check with the following error message: *Quote:*   

> Error: C compiler cannot create executables!

 In that case, revert to the safe set of CFLAGS provided by Bob P in the very first post of this topic, I will not mention them here.

I changed my CFLAGS according to Bob P's advice after "emerge gcc-config glibc binutils gcc". Thus, there are 2 different sets of CFLAGS I used in the install process: one for the 3.3.4 compiler which we have to use in the early stage, and the other set for the 3.4.3 compiler which we use to re-emerge toolchain and system.

The first set of CFLAGS I used (from "emerge -C linux-headers" to "emerge gcc-config glibc binutils gcc"):

removed

The second set (used from "emerge glibc binutils gcc portage" and "emerge -e system", to "emerge splashutils"):

removed

To repeat again: IF your emerges fail using these CFLAGS, change them to the ones used by Bob P in the tutorial (first post) and re-try the emerge.

PS: Remember to adjust -march and -mcpu and -mtune values in the CFLAGS to match your own processor! Do not blindly use the processor value posted here (or anywhere else) without checking. Or you will have problems as thecookie did in his post further on in this topic.  :Wink: 

----------

## thecookie

 *Bob P wrote:*   

> that sequence of commands isn't part of the tutorial, so i really don't understand why you would choose to intersperse it with the commands that are in the tutorial.  if you make changes to the tutorial, you should expect that the ultimate outcome may be different than if you had not.

 

I am sorry for the confusion. I copy/pasted the wrong line, I was watching some other guide at the same time. 

The question was if I was getting the right linux26-headers. portage was emergeing linux26-headers-2.6.8.1-r2 - are those the right ones?

I have another question/problem now. The first time I tried installing from this guide I used the aggresive CFLAGS. It resulted in gcc not being able to create executables after finishing compiling glibc - when trying to compile binutils. I re-did everything, following each step from the guide and using the same make.conf, but with the conservative CFLAGS. After a few hours compiling I get the same result  :Sad: 

```
creating cache ./config.cache

checking host system type... i586-pc-linux-gnu

checking target system type... i586-pc-linux-gnu

checking build system type... i586-pc-linux-gnu

checking for a BSD compatible install... /bin/install -c

checking whether ln works... yes

checking whether ln -s works... yes

checking for gcc... gcc

checking whether the C compiler (gcc -O2 -march=pentium -mtune=pentium -pipe ) works... no

configure: error: installation or configuration problem: C compiler cannot create executables.

!!! ERROR: sys-devel/binutils-2.15.92.0.2-r2 failed.

!!! Function toolchain-binutils_src_compile, Line 106, Exitcode 1

!!! (no error message)

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

Any idea what the problem might be?

----------

## kimchi_sg

 *thecookie wrote:*   

> 
> 
> ```
> creating cache ./config.cache
> 
> ...

 

I believe that you are not using a real classic pentium system to do your emerge, no?

If you are using anything newer than a classic pentium (the one right after the 80486 in the processor lineage), then change your CHOST to i686-pc-linux-gnu and the -march and -mcpu options in your CFLAGS to match the true values for your processor. A wrong processor type in CFLAGS will cause emerge to b0rk like this.

FYI, read the comments about the CFLAGS in /etc/make.conf.example carefully to see what the acceptable processor type values are.

----------

## Bob P

 *Quote:*   

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

 

I'm going to step up onto the soapbox for a moment:

The Documentation, Tips & Tricks Forum really is not a support forum, so I'd prefer if we could limit the context of this thread to posts that discuss problems with the tutorial that need to be corrected, or ideas about how to improve the Stage 1 on 3 installation procedure iteself.

At this time the tutorial has evolved to a fairly mature state, such that most problems that are likely to be encountered during an install are likely to be related to individual factors not attributable to the tutorial.  It would seem fair if those who encountered problems with architecture specification, CFLAGS, etc. could post their requests for help in the appropriate support forums.  (That way, once your personal support request is resolved, your problem will scroll off into oblivion instead of being preserved here forever, interspersed with this documentation.)

I hope that I'm not over-stepping my bounds by trying to moderate this thread, but I am trying to keep it from bloating into another 21-page encyclopedia of randomosity by interspersing support requests with posts that are related to improving the tutorial.

Please post all support requests in the appropriate support forums.  It will make life alot easier on everyone.

Thanks!

----------

## Bob P

 *hielvc wrote:*   

> Bob I ran in to a portage upgrade prob yesterday. I went up to linx26-headers-2.6.8.1-r2. In and of its self this is not necessarily a reason to rebuild your tool chain or do 
> 
> ```
> emerge linux26-headers glibc && emerge glibc binutils gcc && emerge binutils gcc && emerge world -e 
> ```
> ...

 

i was looking at the difference between the -r1 and -r2 versions of the current linux26-headers.  it seems that there is no significant difference between them, and an upgrade without rebuilding the toolchain in this case would seem safe.

----------

## certocivitas

Well I just finished an install using Bob P's method and everything is working great. I'm using an old athlon-xp 2200, here are the compile flags I used:

```
CFLAGS="-O2 -march=athlon-xp -mfpmath=sse -msse -mmmx -m3dnow -pipe"

CXXFLAGS="${CFLAGS}"

LDFLAGS="-Wl,-O1"
```

These are not the most optimized possible I'm sure but after lots of trial and error they are stable (at least for me, YMMV).

I did an install from a working Gentoo system. Using mm-sources, reiser4 worked well (read: it has not crashed and burned yet  :Rolling Eyes:  ). 

One note for nvidia-driver users, You can not compile the driver with mm-sources greater than 2.6.10-r2. You will just get this error if you try:

* EDIT 2.6.10-r2 does not work either  :Evil or Very Mad:  use 2.6.10-r1

 *Quote:*   

>  * Your current kernel uses EXPORT_SYMBOL_GPL() on some methods required by nvidia-kernel.
> 
>  * This probably means you are using 2.6.10_rc1-mm*. Please change away from mm-sources until this is
> 
>  * revised and a solution released into the mm branch, development-sources will work.
> ...

 

Also the /etc/conf.d/rc configuration has changed a little. For a UDEV only system set things like this:

```
RC_DEVICE_TARBALL="no"

RC_DEVFSD_STARTUP="no"
```

Happy hacking.

----------

## Nairou

Out of curiosity... This tutorial claims to be "bulletproof", and indeed is a very enticing choice for my next fresh install. But from what I can tell reading over the pages of posts - and I may very well be wrong - this is essentially a "~x86" setup, leaving "x86" behind for the most part. Is this correct? If so, wouldn't that potentially create stability problems, making it less than "bulletproof"? I've always stuck with "x86" thus far, but my need for GCC 3.4.3 is making me look into alternatives such as this, and I'm wondering if it's going to bite back at some point.

----------

## Bob P

 *Nairou wrote:*   

> Out of curiosity... This tutorial claims to be "bulletproof", and indeed is a very enticing choice for my next fresh install. But from what I can tell reading over the pages of posts - and I may very well be wrong - this is essentially a "~x86" setup, leaving "x86" behind for the most part. Is this correct? If so, wouldn't that potentially create stability problems, making it less than "bulletproof"? I've always stuck with "x86" thus far, but my need for GCC 3.4.3 is making me look into alternatives such as this, and I'm wondering if it's going to bite back at some point.

 

i thought that the post on Page 1 where i quoted robmoss, and the quote at the top of Page 2 about nptlonly spelled this out pretty clearly, but i'll give it another shot just in case i wasn't clear.

in the context of this tutorial, bulletproof has nothing at all to do with your selection of whether or not to participate in testing branch.  rather, it is about how you build your system toolkit so that it will work properly, effectively, efficiently and reliably in building your world files.

"arch" vs. "~arch" really doesn't have anything to do with the stability of your toolkit.    the ebuilds that we use to build this system toolkit are proven, stable, and reliable.  they provide the absolute bleeding edge in performance while keeping stability the primary concern.  once you have your system built, you have the choice of whether or not to use stable "arch" packages or experimental "~arch" ebuilds to populate your world.   

ultimately, if you should decide to stay in the testing branch then the results that you will encounter with ebuilds will have nothing to do with your decision to follow this tutorial -- it will depend entirely upon the ebuilds themselves.  "~arch" is for testing experimental ebuilds.  if you're not inclined to do that, and you want packages that we know are stable, use "arch".  but your decision of which branch to follow after you've installed your system is a decision that should be made independently of your decision to follow this tutorial.

if the prospect of using "~arch" when building your base system scares you, then this installation method is not for you.

----------

## certocivitas

Using ~x86 is not really needed in make.conf to do this install. Adding the packages in the toolchain that require a keyword masked version to /etc/portage/package.keywords will do just fine. After Installing this is all that was in package.kewords:

 *Quote:*   

> =sys-libs/libstdc++-v3.3.3-r1 ~x86
> 
> =sys-devel/gcc-3.4.3-r1 ~x86

 

And everything else was installed with package versions of the more stable x86 type. Well except mm-sources, madwifi and nvidia packages but that was because I deviated from the standard install abit.

----------

## Guinpen

Hello,

I've been following your guide, and on the 258th minute of emerge -e system I get (reproducing by memory):

ERROR: media-libs/svga-lib-1.9.19-r1 failed

Function kernel-mod_configoption_builtin, Line 114, Exitcode 1

Kernel has not been configured yet

If you need support, post the topmost.... (btw tthere is nothing useful, on top of that, it's the download stuff for svga-lib)

So, emerge --resume displays that again and stops, and an emerge -s system, from what I understand, would start ALL OVER AGAIN. If I emerge a kernel source package and configure my kernel, then I suppose emerge --resume will no longer know what I mean, and I'd gave to start again.... in any case, what should I do?

I use the opportunity to thank you for the wonderful guide, and to point out a possible bug - for the very first toolchain compile, which is still with, say, GCC 3.3.4, you're using the -mtune=pentium option which I understand is new to GCC 3.4.3! It did break the binutils configuration on my Centrino (pentium-m) laptop, and removing that fixed the problem.

EDIT: I found out that the way to fix this is to install (and properly point) to the kernel sources. I could do that with emerge whatever-sources, and then I'd create the proper symlink in /usr/src. However, I am afraid that this last emerge would destroy the previous resume information and I would not be able to resume. How can I preserve the resume information?

----------

## Bob P

There are CPU specific problems with older versions of GCC and Pentium-M processor-specifc CFLAGS that are a matter of record if your search the forums.  You might have been caught by that bug.  I'm not sure, but I think that with GCC 3.3.4, the preferred architecture for a Pentium-M is pentium3, but you'd better verify that instead of taking my word on it.  IIRC Pentium-M is a 3.4.3 CFLAG.  maybe somebody else can correct me in on this.

-mtune is indeed a GCC 3.4.3 CFLAG that has been deprecated by the GCC 3.3.4 -mcpu CFLAG.  insofar as we are using the GCC 3.3.4 that came with the Stage 3 tarball to perform our first set of compiles in section 7.1, you should eliminate the -mtune flag from your make.conf or replace it with -mcpu.  then, when you get to section 7.2.1, you should get rid of -mcpu.   you can add-back the -mtune CFLAG if you want to use it, but its not really necessary unless you are compiling on one architecture and optimizing to run on another, as -mtune is implied when you set -march.    Sorry if this was not clear.

EDIT: second paragraph

----------

## ronin69hof

binutils failed with it complaining that the c compiler couldnt create executables so i removed the -mtune=pentium from the CFLAGS line in make.conf and re-emerged binutils and it worked like a charm.

----------

## Fanatic

Worked fine here aswell, it's stable but it doesn't feel much more 'optimised' than it did with gcc 3.3  :Wink:  But apps do seem to compile faster than in gcc 3.3.

```

CFLAGS="-O2 -mtune=athlon-xp -march=athlon-xp -fomit-frame-pointer -fforce-addr -momit-leaf-frame-pointer -frename-registers -fweb -ftracer -pipe"

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

```

----------

## kimchi_sg

 *Bob P wrote:*   

> If you have a question about how to recover from an installation error, please pursue help in the support forums.

 

I think the onus is solely on you to make a topic in the Installation Gentoo forums (or another forum you would deem appropriate for this), expressly for testers of your installation method to voice their requests for help.

The reason for this is that there are people who install their systems using tutorials from Documentation, Tips and Tricks (like this one) to install their systems, and then run into trouble with their install, then do as you have suggested here - post their questions to Installing Gentoo.

But the people who frequently answer posts in Installing Gentoo may have no idea which exact D, T & C tutorial the person in trouble followed, especially since the relevant link is often the last thing they bother to include in their help request.

Therefore, creating a topic in a relevant support forum just for support questions related to the installation method you're proposing, complete with a link to this installation tutorial, would be a great help.  :Wink: 

----------

## Bob P

You've made a good point about the support thread.  People who run into problems following this guide will need some form of support.  I've been spending alot of time in the Installing Gentoo forum looking for people who've needed help, and I've found every thread that's related to this guide.  I'm not sure that its necessary to lump everybody's problems into the same category, though, as this will just create a rather chaotic thread.  What is essential is to be available to help out, and I've been bending over backwards trying to do that.  I'd appreciate it if those people who are credited for helping with the basis for thiis tutorial and are familiar with its techniques could also lend a hand.  :Wink: 

One potential problem has cropped up, being reported by a handful of forum n00bs in the last 24 hours:  a fair number of them have had trouble with emerge linux26-headers-2.6.8.1-r2 stopping with a critical error.   Unfortunately, this problem has not been at all reproducible -- every user seems to have gotten through the emerge on a subsequent attempt, which makes me wonder if a configuration error may have been involved.  FWIW, i have repeated the installation method on my two testbed PCs and i have not been able to reproduce unsatisfactory results.

----------

## kimchi_sg

 *Bob P wrote:*   

> One potential problem has cropped up, being reported by a handful of forum n00bs in the last 24 hours:  a fair number of them have had trouble with emerge linux26-headers-2.6.8.1-r2 stopping with a critical error.   Unfortunately, this problem has not been at all reproducible -- every user seems to have gotten through the emerge on a subsequent attempt, which makes me wonder if a configuration error may have been involved.  FWIW, i have repeated the installation method on my two testbed PCs and i have not been able to reproduce unsatisfactory results.[/b]

 

I have gotten this very same error. It seems to have been introduced by the changes in linux26-headers about yesterday. Cloudburst on #gentoo had the same error as me and we happened to bump into each other last night (GMT +8hrs), so I know this is not a problem specific to your method. He got the same error emerging linux26-headers in a stage 1 install, with ACCEPT_KEYWORDS="x86". And I got him to file a bug report.  :Wink: 

From what he reported, linux26-headers was changed in the last 24 hours or so, and the changelog lists the change as "improved cross-compiling support". Unfortunately, the new version (which still has the same version number) generates a lot of "please upgrade to your package to use linux-info.eclass" errors, during the applying patches stage. Then when the first HOSTCC script is run (<somedir>/fixdep.c), the script will immediately abort, complaining that some include file is not found.

Sorry i can't be more specific about the symptoms, as i have "solved" this by masking the latest version of linux26-headers. But i can reassure you that it is not a configuration problem.  :Wink:  Who knows, it may even be bugfixed by now.  :Very Happy: 

----------

## Bob P

AARGH!

i hate it when this happens.  look here:

http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-kernel/linux26-headers/linux26-headers-2.6.8.1-r2.ebuild

it seems that linux26-headers-2.6.8.1-r1 v1.1 was 5 days old and b0rked.  about 22 hours ago, vapier published 2.6.8.1-r2 v 1.2 (a different version of the software with the same ebuild number) which appears to have fixed the problem.  that's why i couldn't reproduce the problem this morning.

the good news is that the problem was in the ebuild, not in the tut.   :Cool: 

----------

## ronin69hof

great, after an "emerge --sync" the 2.6.8.1-r2 headers finally worked.  thanks for the great tutorial, its much appreciated.

----------

## tonich

problem with linux26-headers-2.6.8.1-r2 fixed here

http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/toolchain-funcs.eclass

----------

## mtamizi

Bob P: Thanks for this tutorial.  It was very useful.

About the CFLAGS.  Most people are using those extra flags without realizing it, ie, some of the flags you listed are redundent.  According to GCC optimization website, -O3 already includes a lot of those options -- like -fomit-frame-pointer.

----------

## Bob P

 *mtamizi wrote:*   

> Bob P: Thanks for this tutorial.  It was very useful.
> 
> About the CFLAGS.  Most people are using those extra flags without realizing it, ie, some of the flags you listed are redundent.  According to GCC optimization website, -O3 already includes a lot of those options -- like -fomit-frame-pointer.

 

indeed, you are right.  whenever you turn on any level of optimization using -Ox, -fomit-frame-pointer is enabled.  you will get -fomit-frame-pointer at -O1, for example.

similarly, when you turn on level -O3, -frename-registers and -fweb are enabled.  i'll fix that.  thanks.

----------

## Hobbit_HK

IIRC, -fomit-frame-pointers is enabled automatically in -Ox if it doesn't interfere with debugging, not the case in x86

----------

## Bob P

 *Hobbit_HK wrote:*   

> IIRC, -fomit-frame-pointers is enabled automatically in -Ox if it doesn't interfere with debugging, not the case in x86

 

Hobbit!  I narrowly beat you to the punch!  :Wink:   Because this tut uses the Intel Pentium example, I've left that flag in.

UPDATE NOTE:  As a result of the recent troubles with defective linux26-headers appearing in the testing branch, I've decided to change the default branch for this installation method to the stable branch.  Hopefully, staying out of the testing branch will improve reliability for those who are less experienced in troubleshooting ebuilds.   More experienced users are free to change this option to suit their needs.

----------

## Hobbit_HK

LOL...   :Razz: 

Good idea on changing to the stable branch btw.. although I'm staying at ~x86  :Smile: 

I just hope I won't hose my install wuth all those guides-merging  :Wink: 

----------

## Bob P

Well, I am sticking to ~x86 on my desktop, but I've decided to use the stable branch for my router.  I don't think that merging and revising the guide is going to hurt us.  To test the latest revisions to the guide, I started a new install on the old boatanchor last night.  It should be done in a few days...   :Embarassed: 

----------

## hielvc

Ever heard of distcc there Bob  :Razz: 

----------

## jack.stay

Given the change in the tutorial to the stable branch, I'm struggling to understand one subtlety related to the installation:

Why does the system compile GCC 3. 4.3 under step 7.1 of the tutorial? Given that the make.conf now includes ACCEPT_KEYWORDS="x86"  I was expecting to see something like   sys-devel/gcc ~x86   in package.keywords prior to emerging gcc in this step.

I am a complete new comer to Linux, but I have been following the progress of this tutorial with great interest. It has been a wonderful learning experience.

----------

## Insanity5902

i am going to take a shot in the dark but ...

with a ACCEPT_KEYWORDS="x86" you end up an extremely stable system and aren't testing out packages.  What you need to do to still use gcc 3.4.3 and other select packages is add them to your /etc/portage/package.keywords

so a simple command like this

```

echo sys-devel/gcc ~x86 >> /etc/portage/package.keywords

```

This is what I startedto do one my laptop, added only packages that have advanced features I want, or ones that are masked with the ~x86.  It will create a truly customized and a hell of a lot more stable system then a pure ~x86.

The reason we are going to go ahead and emerge gcc3.4.3 b/c it can provide some big speed imporvments for you system.

I am built my server very close to this guide before it came out and I am going to rebuild my desktop to this.  And I am going to update my laptop to gcc 3.4.x this summer (after this semster of college).

I honestly think this guid along with a x86 system utlizing package.keywords should be the standard for those wanting a very fast system, yet stable as possble.  IMO, this guide gives you everybit of performance and still provides a lot of stabilty.  The simple fact it isn't a pure x86 could mean you are giving up some stabliity

----------

## lockfree

when i "emerge gcc-config glibc binutils gcc", it takes a really long time - 14 hours and still ongoing...

My server is a pentiumpro 200MHz with 10k rpm scsi harddisk.

Is this normal? How long did you take to emerge the line above?

----------

## Iron_DragonLord

200 MHz...? Sounds normal to me.

Took 48 hours straight or more (I think, I was of course asleep at night when I let it run) on my 500 MHz AMD K-3 with just a normal stage 1 install. This was on my server, thus no KDE or anything for graphics, too.

----------

## lockfree

It has taken abt 10hours before that. Running that line of command alone is > 14hrs and counting.. and after choosing the default C compiler to 3.4.3, i need to run that command again.. man! that's a pretty long time!

Anyway, how to have xcfe as the default windows manager, instead of kde, gnome, etc. At which stage in this manual should it be configured and how? 

Thanks.

----------

## hielvc

My old p166 would take at least 5,may have been 7, days to build through gnome and mozilla it had 128Megs ram. 

I agree with jack.stay  that sys-devel/gcc needs to be added to /etc/portage/package.keywords as all versions of gcc above gcc-3.3.4-r1 are "~x86".

----------

## Bob P

 *hielvc wrote:*   

> Ever heard of distcc there Bob 

 

 :Embarassed:   well, yes i have... but its not doing me any good as i've i've got all 3 of my machines compiling their own stuff right now!  

i also have to assume that some of your ribbing was in jest, as we all know how distcc will b0rk up compilation when the two machines are running different versions of gcc!  the fact we're migrating from 3.3.4 to 3.4.3 makes distributed compilation a tricky implementation.   :Idea: 

i am also somewhat biased against using distcc when testing modifications to the tutorial -- i want to limit failures to failures in the tutorial itself, and i don't want to be subject to distcc-induced complications.  unfortuantely, distcc adds its own set of potential problems.  sometimes its just "cleaner" not to use distcc.

----------

## Bob P

 *jack.stay wrote:*   

> Given the change in the tutorial to the stable branch, I'm struggling to understand one subtlety related to the installation:
> 
> Why does the system compile GCC 3. 4.3 under step 7.1 of the tutorial? Given that the make.conf now includes ACCEPT_KEYWORDS="x86"  I was expecting to see something like   sys-devel/gcc ~x86   in package.keywords prior to emerging gcc in this step.
> 
> I am a complete new comer to Linux, but I have been following the progress of this tutorial with great interest. It has been a wonderful learning experience.

 

Jack, if you're a newcomer, you're doing a good job and you're catching on quickly.   :Wink: 

yes, GCC 3.4.3 is in the testing branch, and by changing the keywords in make.conf to use the stable branch instead of the testing branch, we'd torpedo our ability to use GCC 3.4.3.  the key to success, as both you and Insanity pointed out, is to explicitly specify the testing branch for GCC in /etc/portage/package.keywords.  

Unfortunately, the tutorial doesn't yet reflect the necessary changes to implement the stable branch -- I am midstream in prototyping the changes on a testbed PC and I haven't gotten far enough to update the tut yet.  From a theoretical standpoint, if you use the step that Insanity recommended (just before updating the Portage tree in section 6.6.x) you should be good to go.  :Wink:   don't forget to also add libstdc++-v3 as it is a required dependency.

Insanity, I've been spending the day working on the testbed PC, fixing a b0rked Windows box (dammit!) and updating the PDF along the way.  Once that's finished I'll update the tut and let you know that the hardcopy is updated as well.

lockfree, if you're doing this install on a P200, you are one serious glutton for punishment.  the steps in section 7.1 alone will proably take you 36 hours on that hardware.  for a full installation, you're probably looking at at least a week of compilation!    :Shocked:   didn't you take me seriously when you read the warning at the beginning of the howto?

 *Bob P wrote:*   

> WARNING: This is an ADVANCED installation method. The amount of time required for you to complete this type of installation will equal or exceed that of any other Gentoo installation method. Your time will be well invested, though, as the result will be a very stable Gentoo system. This installation method may prove to be somewhat difficult and cumbersome for users who are new to Gentoo. It will prove especially painful for users who plan to install Gentoo old hardware. 

 

I really need to pick-up a couple of more testbed PCs -- after writing this tut it became painfully obvious that I need some faster testbeds.   :Rolling Eyes: 

----------

## mtamizi

 *seringen wrote:*   

> does a normal person really need to be running xinetd?

 

Since there was no update in the tutorial, I recommend everyone who will add xinetd to their default run level read Securing Services in the Gento Security Guide.  As a general rule, if you don't know what xinetd or inetd are, you don't need them.  Although I do recommend learning what xinetd is and what it is used for.

----------

## gnough

 *Quote:*   

> I would like to request that users who do not fully understand why certain critical steps in the guide are being taken should refrain from making recommendations to remove them just because they fail to understand them.

 

The post I wrote here was a complete garbage.

Sorry for making such a stupid comment.Last edited by gnough on Fri Jan 14, 2005 12:20 am; edited 1 time in total

----------

## hielvc

Heres a automated wrapper for emerge that will emerge world -uD unless linux26-headers or glibc are being updated in which case it rebuilds the toolchain first and then with an edited list emerges the rest of package list.

 This script is meant for use after you've built your system and want to quarantee a stable toolchain.

```
#!/bin/bash

# 

# Date 1-12-05 version 1.0, Hiel Van Campen

# Use at yee own risk. It works for me, but then I wrote the damn thing.

# A wraper to run emerge world -uD

# It chechs if linux26-headers or glibc are being updated and if so runs the 

# toolchain thang. It then uses an edited -uDp generated list wtih toolchain items removed to

# emerge the rest of the list

# 

# Toolchain thang

# emerge linux26-headers glibc && emerge glibc binutils gcc && emerge binutils gcc

#   

## Changed the to use awk as it removes toolchain items in one pass

#           

#   cut -f2 -d "]" -s wrld.lst|awk '!/glibc|glibc|binutils|gcc/ {print $1}'

##

##   

##  The build script for the edited wrld.lst-->build.lst. Anything that fails to emerge

##  is copied to failed.lst  To view the build.lst or failed.lst use "less failed.lst"

##  for i in $(< wrld1.lst);do emerge --oneshot  =$i || echo $i>> failed.lst;done 

##   

a=0  # If 0 then update doesnt have linux-headers or glibc update and continue emerge. If set to 1 then

     # rebuild toolcahin and then emerge from the build list after running toolchain thang. 

:>build.lst   # empty build.lst and wrld.lst other wise the next time they are run theyll still have 

:>wrld.lst    # the old stuff in them plus any new stuff, could becaome a very long list.

:>failed.lst  # empty failed.lst so that only those that failed this time are listed  

emerge world -uDp>>wrld.lst

if echo "linux26" | grep -q linux26 wrld.lst

   then a=1

elif echo "glibc" | grep -q glibc wrld.lst

   then a=1

fi

if [ "$a" -ge "1" ]

   then   

   for line in $(cut -f2 -d "]" -s wrld.lst|awk '!/glibc|glibc|binutils|gcc/ {print $1}')

   do echo $line>>build.lst

   done

   

   echo "Found glibc or linux26-headers rebuilding toolchain"

   

   emerge linux26-headers glibc && emerge glibc binutils gcc && emerge binutils gcc \

   && for i in $(< build.lst);do emerge --oneshot  =$i || echo $i>> failed.lst;done

   

         

   else 

   echo "No glibc or linux26-headers update so procedeing with regular emerge world -uD."

   emerge world -uD

   

fi

exit 0
```

Cut and paste into a text editor, save as emerge_wrapper.sh. then "chmod 774 emerge_wrapper.sh. You can then copy to /usr/local/bin/ and run it.

----------

## Bob P

 *gnough wrote:*   

> I think what Bob wants to do in emerge -e system with rsync-restriction stuff is to exclude recompilation of glibc, binutils, gcc, linuxheaders26.
> 
> 

 

No, let me clarify that.  In following this guide, you should not restrict rebuilding of the toolkit in any way.  The steps in rebuilding the toolkit have been carefully planned and there are no unnecessary steps in them.  Each iteration of the system build is absolutely necessary to ensure system stability, and modifying the sequence of events will only cause problems to pop-up farther down the road.  

My only recommendations about restricting rebuilds of the toolkit were made in the context of updating a completed Gentoo installation on subsequent world emerges/updates, not system emerges.  There's a huge difference between them and its important to understand the difference.  

Sorry if  a failure to clarify things on my part led to this misunderstanding.

I'm going to rant a little bit on this subject in my next post.  I've had alot of people contact me via PMs with questions like these, so although I'll be using your case as an example, please don't get the impression that this is directed at you.

edit:  changed "redundant" to "unnecessary" in second sentence.

----------

## Bob P

 *gnough wrote:*   

> ok. This is my first stage1 equivalent installation..
> 
> I followed up until:
> 
> ```
> ...

 

That approach may save you some time, but saving time by using a half-baked approach to rebuild your toolkit after switching C compilers is absolute false economy.  You are going to seriously undermine the stability of your Gentoo box by selectively choosing to follow some sections of the tutorial and not others, especially if you decide to throw away some of the sections about building the toolkit.  The stability of the system absolutely requires that you take the extra steps to build the toolkit properly, and the stability of your toolkit absolutely requies that you follow ALL of the steps, not just the ones that look good at a casual glance.

A Stage 1 on 3 installation is significantly more complex than a Stage 1 installation method because the contents of the tarballs differ.  The difference in the content of the tarballs requires that additional steps be taken to change the system headers, compilers and libraries, AND to redundantly rebuild the system toolkit after making such a change.

It makes absolutely NO SENSE that anyone would choose to use THIS tutorial on how to build a Stage 1 system on a Stage 3 tarball if they should plan to excise critial steps along the way.  Even limited experience with Stage 1 type installations, the GCC compiler, and rebuilding Gentoo system toolkits should prevent the reader from contemplating such an approach unless he doesn't really understand the focus of this installation guide.  

As I had mentioned in the header to this guide, this is an alternative method to building Gentoo that is guaranteed to take longer than any other currently published method of building Gentoo.  It makes no sense that anyone should choose to follow this installation guide if they do not have sufficient time to complete the installtion procedures.  If time is a critical factor, there are other ways to build Gentoo that will take less time, that will not require emasculation of the procedures to achieve a speedier finish for the impatient.

There is absolutely NO GOOD REASON for skipping the steps where the toolchain is rebuilt.  Rebuilding the toolchain in a redundant fashion is the focal point of this installation method.  Everything in the tutorial up to that point is just series of supporting steps to bring the reader to the point where they can safely rebuild their toolkit.  This entire installation method was designed around this step!  Skipping this step will seriously undermine the robust nature of this Gentoo installation method.  Readers who do not intend to perform this step have been wasting an awful lot of time (time is money!) by following this installation guide -- by deleting some of the apparently "unnecessary" steps, the "bulletproof" nature of this installation method will be seriously undermined.

While I appreciate the helfpul suggestions that have been made in an effort to refine the content of this guide, I would like to request that users who do not fully understand why certain critical steps in the guide are being taken should refrain from making recommendations to remove them just because they fail to understand them.  Other less experienced people may read such comments and choose to follow such ill-advised methods without understanding the perils that would lie in store for them.

On the subject of skipping a toolkit rebuild on subsequent world updates, yes, control over rebuilding of the toolkit is an important consideration for maintaining the stability of your Gentoo system -- but you should NOT be avoiding a complete rebuild of the toolkit because it takes too much time, as that is absolute false economy!  

Unplanned rebuilding of isolated toolkit components in a single pass is to be avoided because a more throrough approach (think robmoss) is required to assure toolkit stability and total system stability after a major toolkit component is changed.  Masking of the toolkit components may be useful for those with time constraints who wish to delay toolkit rebuilds until such time as they can appropriately addressed.  I have done it, and I have written a tutorial on how to do it.  I've decided not to publish it though.  Everyone familiar with Portage should have no problem performing such a task, while those who aren't sufficiently familiar with Portage may be best advised not to bother.

----------

## Clyde

(I post this not as a newcomer seeking support, but in the spirit of proofing/improving the tutorial.   :Wink:  )

1.  Which, if any, of the USE flags in section 6.5 are considered required before building the toolchain? I ask because several of them are not in the global use.desc, specifically:

   freetype hal ide ithreads pthreads userlocales

although some are in use.local.desc for certain packages. 

2.  9.3 should read "Gensplash"

----------

## Insanity5902

these are all used to to build the system

As I understand it, on a very basic level ...

Global use flags are for more the one package, hence the global tagging.

Local use flags are for specific apps.

What some people do is do a look up on all the use flags they use.  If it is global that add it to the make.conf if it is local they put add it to /etc/portage/package.use

```

echo <package-level>/<package-name> <useflags> >> /etc/portage/package.use

```

----------

## mtamizi

I'm finishing up an install using this tutorial and I came across a problem when emerging ttmkfdir -- a dependency for x11.  I fixed the problem by first doing the following:

```
ACCEPT_KEYWORDS=~x86 emerge libtool
```

----------

## kimchi_sg

 *mtamizi wrote:*   

> I fixed the problem by first doing the following:
> 
> ```
> ACCEPT_KEYWORDS=~x86 emerge libtool
> ```
> ...

 

Uh huh. I wouldn't induce ACCEPT_KEYWORDS=~x86 so easily.

Simply emerging libtool twice in a row should solve the problem.

```
emerge libtool && emerge libtool
```

----------

## thecookie

If anyone was wondering;

https://forums.gentoo.org/viewtopic.php?p=1976103

How does this affect the recompiling of the toolchain? Is it needed if gcc dosn't take all the new flags?

Is the newer gcc more optimized in general compiling too?

----------

## mtamizi

 *kimchi_sg wrote:*   

> Simply emerging libtool twice in a row should solve the problem.
> 
> ```
> emerge libtool && emerge libtool
> ```
> ...

 

Why would that work?

----------

## Bob P

 *mtamizi wrote:*   

> I'm finishing up an install using this tutorial and I came across a problem when emerging ttmkfdir -- a dependency for x11.  I fixed the problem by first doing the following:
> 
> ```
> ACCEPT_KEYWORDS=~x86 emerge libtool
> ```
> ...

 

well, you've brought up an interesting question.  installing x11 is somewhat beyond the scope of this thread, but since its a very popular program that alot of people will be installing, i'd like to hear more -- especially since others have done it without problems while you seem to have hit an obstacle.  unfortunately, you haven't given us any specific information to go on.  we need more information from you.  there are going to be alot of questions specific to your application/installation that may not be relevant for everyone else.  could you start a support thread in the Desktops forum so that we can pursue the subject there?

----------

## Bob P

 *Clyde wrote:*   

> Which, if any, of the USE flags in section 6.5 are considered required before building the toolchain? I ask because several of them are not in the global use.desc, specifically:
> 
>    freetype hal ide ithreads pthreads userlocales
> 
> although some are in use.local.desc for certain packages. 

 

unfortunately, the state of documentation for use flags is somewhat behind the times.  there are already over 100 undocumented use flags, which makes the subject of use flags a difficult one to address.

hal is a use flag that is invoked by one of the gnome packages.  if you don't use gnome (and none of your packages have gnome dependencies), you can remove it.

userlocales is used by glibc.  this should be evident, as its discussed in the tutorial.

to be honest, i don't remember exactly where i picked up freetype, but iirc it came from X11 or some X program.  

ithreads and pthreads are necessary for the system.  they are also poorly documented.  ithreads is specifically needed to fully support nptl by perl/libperl.  i had never heard of the flag until i saw it roll across the screen as i watched perl/libperl compile.  if you don't use ithreads, perl/libperl issue screen output asking you to set that flag and then recompile them.  

i guess that the moral of the story is that somebody expects us to sit at our computers and actually read the text output that's displayed when programs compile!    :Idea: 

----------

## DrWoland

 *Fanatic wrote:*   

> Worked fine here aswell, it's stable but it doesn't feel much more 'optimised' than it did with gcc 3.3  But apps do seem to compile faster than in gcc 3.3.
> 
> ```
> 
> CFLAGS="-O2 -mtune=athlon-xp -march=athlon-xp -fomit-frame-pointer -fforce-addr -momit-leaf-frame-pointer -frename-registers -fweb -ftracer -pipe"
> ...

 

I used these same flags and so far so good - booted fine, everything works fine. I'll see when I get home from work if nvidia and xorg emerged properly.

----------

## Bob P

 *Bob P wrote:*   

> ithreads and pthreads are necessary for the system.  they are also poorly documented.  ithreads is specifically needed to fully support nptl by perl/libperl.  i had never heard of the flag until i saw it roll across the screen as i watched perl/libperl compile.  if you don't use ithreads, perl/libperl issue screen output asking you to set that flag and then recompile them.  

 

i left out the part about NPTL.  if you compile perl/libperl without NPTL support, you won't see the ithreads message.  IIRC, if you compile perl/libperl with the nptl use flag set, then they look for the status of the ithreads flag and issue an error warning if both ntpl and ithreads are not both set.  at least that's the way i remember it.   :Wink: 

----------

## jerickson314

There is already a thread open for the libtools/ttmkfdir error at https://forums.gentoo.org/viewtopic.php?p=1977938.

----------

## kimchi_sg

 *mtamizi wrote:*   

>  *kimchi_sg wrote:*   Simply emerging libtool twice in a row should solve the problem.
> 
> ```
> emerge libtool && emerge libtool
> ```
> ...

 

Honestly, I do not know. But I know it works. I had that problem, and that was the fix.

If I want total system stability, a libtool error would NEVER be an excuse to use ACCEPT_KEYWORDS=~x86 so easily. Unless a dev in the bugzilla tells me to, I suppose.

----------

## mtamizi

Bob P, I noticed you never started hald or added it to the default run level using rc-update.  Why is that?  I've never used hald, but I don't understand why you would add it to your USE flag if you never use it.

----------

## Hobbit_HK

Because the hal USE Flag was just for the example make.conf, and not everyone wants to use it, so it'll be wrong to insert it as a part of the tutorial.

----------

## ReiserFS

BOB, thank you for your hard working. you tut is really useful and wonderful! but I have some problem to ask. could you explain the CXXFLAG more detailedly ?? yes, the parameter fvisibility-inlines-hidden and fivisibility=hidden. 

becuase I look for these two parameters in the online manual for GCC 3.4.3, I can not find any thing about them.,even in the options summar pages.

here is the GCC options summary pages for GCC 3.4.3:

http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Option-Summary.html#Option-Summary

Thank you

----------

## ReiserFS

OK, by the way. the -fomit-frame-pointer option is turn on defaultly when any   -On (-O1 -O2 -O3 -Os)is turn on. and the frename-registers and fweb options are turuned on when -O3 is turned on.

Thank youLast edited by ReiserFS on Sun Jan 16, 2005 11:58 am; edited 1 time in total

----------

## ReiserFS

Also the specifying -march=cpu-type implies -mtune=cpu-type.Last edited by ReiserFS on Sun Jan 16, 2005 11:58 am; edited 1 time in total

----------

## Bob P

 *ReiserFS wrote:*   

> BOB, thank you for your hard working. you tut is really useful and wonderful! but I have some problem to ask. could you explain the CXXFLAG more detailedly ?? yes, the parameter fvisibility-inlines-hidden and fivisibility=hidden. 

 

thank you for your compliments.  if you look through the previous posts in this thread, you'll find that we've already discussed the "reduncancy" in some of the cflags that are automatically turned on when you specify varying levels of code optimization with the -Ox flag.  

you can find the CXXFLAGS described in the man pages for gcc.  if you type "man gcc" at the command line, you'll find what you're looking for.  the man pages for gcc are rather extensive, so it will take some thorough reading on your part.  i don't think that its worth copying more documentation into this thread, so i'll refrain from copying the documentation pages and posting them here.  if you have specific questions, you may want to look at some of the other threads on the board.  the common questions have already been asked and answered, and there is a detailed discussion of CFLAGS in the portage and programming forum, and in the gcc 3.4.3 thread.

----------

## Spinner_Kontrol

 *kimchi_sg wrote:*   

> Bob: I stand corrected on the aggressiveness of these cflags. 
> 
> Just a little correction to the amended CXXFLAGS... there should be a space after the curly bracket that ends the CFLAGS, and before the - that starts -fvisibility-inlines-hidden. Otherwise -fvisibility-inlines-hidden will be tacked onto the last CFLAGS option as one word. 
> 
> 

 

naah, it's all good, notice the space before the trailling quote? the -fvisibi... will be tacked onto the end of the space making the space-fvisibil... all one word, which is a good thing!

 :Smile: 

but you're right to point it out - always better to have to many spaces between stringes than 1 not enuf  :Wink: 

----------

## ReiserFS

OK, just small typos: in your pdf file for this tut  :Smile: 

EDIT 1:   in 5.4.3

#echo "PORT_LOGDIR=/var/log/portage" >> /etc/make.conf  

this line is useless. you can get it by de-comment a line in make.conf

EDIT 2: in 5.4.3

#mkdir /var/log/portage

should be 

#mkdir /mnt/gentoo/var/log/portage

you have not chroot in now!!

EDIT 3: in 5.4.3

ok, again here you should add the following line, or the emerge --sync will complain  :Smile: 

#mkdir /mnt/gentoo/usr/local/portage

because you have turn on the "PORTDIR_OVERLAY" in make.conf

EDIT 4: in 6.6.1

#mkdir /etc/portage

this line is useless, the directory has been created by default.

I hope your tut can benifit more persons!

----------

## kimchi_sg

Hey another HK guy in here!!! Nice! I am from HK too. Long time ago.  :Very Happy: 

 *ReiserFS wrote:*   

> OK, just small typos: in your pdf file for this tut 
> 
> EDIT 1:   in 5.4.3
> 
> #echo "PORT_LOGDIR=/var/log/portage" >> /etc/make.conf  
> ...

 

That is not true, the PORT_LOGDIR line that is commented out is in /etc/make.conf.example , and you would need to overwrite /etc/make.conf with /etc/make.conf.example before your statement applies.

----------

## ReiserFS

 *kimchi_sg wrote:*   

> Hey another HK guy in here!!! Nice! I am from HK too. Long time ago. 
> 
>  *ReiserFS wrote:*   OK, just small typos: in your pdf file for this tut 
> 
> EDIT 1:   in 5.4.3
> ...

 

NO, NO the simplest way to compile the make.conf is:

cp make.conf.example make.conf

Then what you will do, is to de-comment several "#" , after that 

a perfect make.conf will given!! with enough comments!!

This is the best way to do this job, I am tired of typing, typing,typing...

NICE to meet you HK gentooer!

----------

## Bob P

 *ReiserFS wrote:*   

> OK, just small typos: in your pdf file for this tut 
> 
> 

 

Thanks, but those topics have already been addressed.

The tutorial states in plain language that the PDF file is not up to date, and will not be updated as often as this guide:

 *Bob P wrote:*   

> 12. Downloadable PDF Now Available 
> 
> A copy of this Tutorial is now available in PDF format. Click Here. Please note that it may not be updated as often as this tutorial. 

 

I hate to point out the obvious, but you need to look at the revision date of the PDF and the revision date on the Installation Guide in the Gentoo Forum and pay attention to which one is more current.  :Wink: 

The Revision History section of the Installation Guide mentions several changes to the guide that have been made since the PDF was published, including a major revision where the guide reverted back to the testing branch.  Insofar as I cannot travel back in time, your only choices are:

1.  to use the Forum Installation Guide,

2.  to wait until the PDF guide is updated, or

3.  to apply the subsequent revisions in the guide to the PDF document on your own.  

Sorry for the inconvenience.   :Rolling Eyes: 

----------

## Bob P

 *ReiserFS wrote:*   

> NO, NO the simplest way to compile the make.conf is:
> 
> cp make.conf.example make.conf
> 
> Then what you will do, is to de-comment several "#" , after that 
> ...

 

it seems absolutely trivial to initiate any discussion about  how a person decides to go through the mechanical aspects of creating a line item in a configuration file.    if you do not like to type the command line instruction that contatenates the make.conf file with the necessary statement, you are free to use a text editor.  linux is about choice, so have it your way. 

to initiate this sort of conversation in this thread seems absolutely futile and a waste of everyone's time.  i hope we won't perpetuate it.

----------

## Bob P

 *Spinner_Kontrol wrote:*   

> 
> 
> naah, it's all good, notice the space before the trailling quote? the -fvisibi... will be tacked onto the end of the space making the space-fvisibil... all one word, which is a good thing!

 

Spinner, thanks for your affirmation of the current state of the CFLAGS example.  but don't assume that kimchi_sg is wrong, just because the CXXFLAGS statement looks right today.  as it turns out, kimchi_sg was absolutely right when he pointed out a typographical error that i had made!  :Wink:   the fact that its subsequently been corrected means that you no longer need to be on the lookout for it.   :Cool: 

----------

## pencechp

Hey, great tutorial!

I notice that you don't ever mention in the tutorial to run an emerge -p gcc, leaving both the old i386-compiled 3.3.4 and the new i[5/6]86-compiled 3.4.3 installed in parallel.  You might add a note that it's a generally good idea to remove that old compiler.  Or is it that not actually a good idea?

----------

## Hobbit_HK

I think some packages require GCC3.3, so it's not necessarily a good idea.

----------

## pencechp

Well, in that case, should you re-emerge GCC 3.3 using GCC 3.4?  It just seems odd that you're leaving the original 3.3 from the stage3 tarball on a system that otherwise has such a bright and shiny toolchain.

----------

## Hobbit_HK

Hmm.. I don't know... Maybe it'll cause trouble if you'll compile programs with gcc3.3, which was compiled with gcc3.4?

----------

## thebigslide

Bob, excellent writeup.  I used the meat and potatoes to upgrade my 2.4GHz Athlon system and it's runnin' sweet.  It's in the middle of the first emerge -e world.  I tried this on my router which cacked with an internal compiler error when compiling gcc the first time.  It's the rsync server and distfiles depository for my network so I can't take it down right now (I always seem to be recompiling something), but I'm going to just reinstall from stage 1 ala 3 following your guide in a bit.

----------

## Iron_DragonLord

Awesome tutorial, I'm still emerging my desktop manager though so I've yet to test it.

Anyway I'd just like to confirm that media-lib/tiff wouldn't emerge for me with "fvisiblity=hidden" cxxflag.

So just for that package I turned it off, I got it back on again.

----------

## Bob P

 *Iron_DragonLord wrote:*   

> Awesome tutorial, I'm still emerging my desktop manager though so I've yet to test it.
> 
> Anyway I'd just like to confirm that media-lib/tiff wouldn't emerge for me with "fvisiblity=hidden" cxxflag.
> 
> So just for that package I turned it off, I got it back on again.

 

thanks for the compliments, guys.

i'd like to say something about the selection of CFLAGS and CXXFLAGS.  time has proven that those of you who have followed this installation guide's recommended CFLAGS haven't been having any problems.  i'm glad to hear that the installtion method has helped as many people as it has.  :Cool: 

it comes as no surprise to me that people who blindly insist on using all of the CFLAGS that i have used to build the toolkit on my system have encountered problems in using some of them to compile other ebuilds.  the fact that it comes as a surprise to some of you seems to suggest that you have some misconceptions about CFLAGS.  so maybe a little more needs to be said about them. 

frist, if you choose to use CFLAGS that are not specfically recommended by this installation guide, then the problem lies in your selection of CFLAGS, not in the installation guide.  if you choose to use CFLAGS that are not listed in the guide's sample make.conf file, you do so at your own risk.

second, this installation method is really about building a stable and optimized gentoo toolkit.  the CFLAGS settings that i have used to build my systems work as advertised for building a stable and optimized toolkit  -- there is no guarantee that the CFLAGS that i have used are going to work on every application that you try to comple.  actually, you should expect that any advanced/optimizing collection of CFLAGS should not work on every ebuild that you encounter!  (more on that later.)   so i do not find it at all surprising that some of the optional CFLAGS mentioned in this guide, which provide the most optimal toolkit build, may not work with some other programs, such as X11 programs or programs that run on the X11 platform. 

as much as i think it is important to build a stable gentoo installation that will run an Xorg with stability, the scope of this installation guide is about installing gentoo, not about installing and supporting Xorg packages, media viewers, etc.  if you should find that there's a fundamental flaw in this installation method that absolutely prevents Xorg from installing, that would probably be an interesting thing to mention, but let me say this -- its not going to happen.  

the toolkit that you build with the ebuilds in today's portage tree are sound.  whether or not you are successful in compiling any ebuild not addressed in this tutorial depends entirely upon how you configure your CFLAGS to compile that individual application and how well designed the ebuild turns out to be. the fact that an image viewing ebuild isn't friendly to all of the CFLAGS that i used to build an optimized toolkit really isn't relevant to this thread -- its an issue with the ebuild.

problems with individual ebuilds that bork on any specfic CFLAGS settings are attributable to the ebuilds themselves and not to the toolkit that has been built using this installation method.  that could change tomorrow, if a bad toolkit finds its way into the portage tree, but in the absense of that happening, there is nothing to worry about.

if you have problems emerging other programs after you complete your gentoo installation using this method, you really should not post about it here.  the best place to address ebuild-specific problems are the appropriate forums for those applications -- in this case the Desktop Environments forum.  a finicky ebuild that isn't a part of the gentoo base system doesn't really have anything to do with building an optimized toolkit or installing gentoo.  

with that said, i'm glad to see that some of you have found the answer -- by customizing your CFLAGS to accomodate ebuilds that are troublemakers.

there seem to have been quite a few posts coming from new users to the forum that seem to share a common misconception about what this installation guide is supposed to do for them:  they expect that this installation method should prevent them from having problems installing any software package that they should choose to install after installing Gentoo.  imho, that's a rather optimistoc assumption to make.  the gentoo system that you build using this tutorial is going to work just as well as any other Gentoo system (probably better!)  as good as this installation guide may be, it won't prevent problems from popping up that aren't caused by it.  i'm guessing that some of the new users may have a misconcepton about this because they're not familiar enough with Gentoo to know exactly where the problems lie.  hopefully that will come with time.

thanks again, everyone, for the feedback!

----------

## Bob P

 *pencechp wrote:*   

> Hey, great tutorial!
> 
> I notice that you don't ever mention in the tutorial to run an emerge -p gcc, leaving both the old i386-compiled 3.3.4 and the new i[5/6]86-compiled 3.4.3 installed in parallel.  You might add a note that it's a generally good idea to remove that old compiler.  Or is it that not actually a good idea?

 

 *pencechp wrote:*   

> Well, in that case, should you re-emerge GCC 3.3 using GCC 3.4?  It just seems odd that you're leaving the original 3.3 from the stage3 tarball on a system that otherwise has such a bright and shiny toolchain.

 

well, i can't say that i can give you a conclusive answer about this, but i can tell you what i thought about when i wrote the tutorial.  maybe somebody else will chime in with a better way to look at the problem.  so from my perspective, let's think about this:  the objective for this tutorial is to design a system that is as robust and failsafe as possible.  let's keep that requirement in mind as we walk through the process of building our toolkit.

we start off with a very stable version of gcc 3.3.4 that comes with the stage 3 tarball.  we subsequently emerge a new version of gcc 3.4.3 that we compile using gcc 3.3.4.  then we compile it using gcc 3.4.3-built-on 3.3.4 to create gcc 3.4.3-built-on-3.4.3-built-with-3.3.4.  finally, we recompile it again to create gcc 3.4.3 using a 3.4.3 compiler that was built with a 3.4.3 compiler.

now you suggest that we get rid of our initial stable copy of 3.3.4-built-on 3.3.4, and replace it with a copy of 3.3.4 built with 3.4.3.  in deciding whether or not to do this, its important to consider the pros and cons of doing something like that:

Pros:

1.  3.3.4 built by 3.4.3 might be better

Cons:

1.  3.3.4 built by 3.4.3 might not be better

2.  recompiling 3.3.4 takes alot of time, and offers undefined benefits

3.  the original version of 3.3.4, if left unmolested, remains on our system as a fallback compiler for programs that may not compile with 3.4.3

4.  if any unrecognized errors are introduced into our toolkit by gcc 3.4.3, recompiling 3.3.4 with 3.4.3 could compromise the integrity of our fallback compiler.

so the way i've thought about there's one potentially good reason for recompiling gcc 3.3.4, and plenty of good reasons not to.  that is of course, not to say that i have all the answers -- those are just the answers that i was able to come up with.   :Wink: 

----------

## Bob P

NOTICE::  

 :Exclamation:  PDF INSTALLATION GUIDE SYNCHRONIZED WITH ON-LINE INSTALLATION GUIDE. :Exclamation: 

As of the date and time stamp on this message, the PDF version has been updated to reflect all of the changes that have been applied to the on-line version at the beginning of this thread.

Have Fun!  :Cool: 

----------

## ReiserFS

successfully installed on IBM T42, with default settings in the tut. except -march=pentium-m thank alot!

enjoy it!

----------

## kimchi_sg

I forgot my own really successful install using this tutorial.

IBM Netvista with P4 1.7ghz, 1024MB RAM and 40GB disk.

P.S. I used my custom set of CFLAGS though.

Now compiling programs feels snappier, and acroread loads in less than 2 seconds flat!

----------

## piwacet

Thanks very much for this tutorial- it's great; I'm in the middle of installing right now!

Quick question.  From reading other threads in these forums on upgrading from gcc 3.3.4 to 3.3.5, it seems some packages would not compile without first running the script:

```
fix_libtool_files.sh 3.3.4
```

Any role for a simmilar command here when we switch to gcc 3.4.3 as default compiler?  Sorry if the answer is obvious, but I have not been able to figure it out.  I also wasn't sure if this was the wrong thread to post in, I can re-post if necessary.

----------

## Bob P

 *piwacet wrote:*   

> Thanks very much for this tutorial- it's great; I'm in the middle of installing right now!
> 
> Quick question.  From reading other threads in these forums on upgrading from gcc 3.3.4 to 3.3.5, it seems some packages would not compile without first running the script:
> 
> ```
> ...

 

i'm kinda surprised by the question, but no, we're not doing the upgrade that your suggested bugfix applies to -- we're leapfrogging over it -- so you shouldn't run into any problems like that.   :Wink: 

----------

## piwacet

Ah, thanks.  I did not realize that that script was so specific a bug fix, applying to just one version of the compiler.

Thanks a lot for the tutorial.  I'm still compiling, and looking forward to my new system!

----------

## rjw8703

I tried to emerge gentoo-dev-sources and I got this error.

Calculating dependencies ...done! 

>>> emerge (1 of 133) media-libs/svgalib-1.9.19-r1 to / 

>>> md5 src_uri  :Wink:  svgalib-1.9.19.tar.gz 

!!! ERROR: media-libs/svgalib-1.9.19-r1 failed. 

!!! Function kernel-mod_configoption_builtin, Line 114, Exitcode 1 

!!! kernel has not been configured yet 

Any clue what might have caused this?

----------

## Bob P

i've never seen anyone have 133 dependencies trying to emerge gentoo-dev-sources.    :Shocked:    it doesn't look like you followed this tutorial, or if you have, it looks like you've deviated from it along the way.  :Embarassed: 

since this isn't a support forum, please ask this question in the appropriate support forum.  thanks!

----------

## Doom0r

Wonderful installation guide, only a few things left floating about to nail it dead on. I'm emerging my x server on my first install and installing another box of my buddy's.

On the note of issues with the guide and direct problems to getting a working system, specifically necessary major components and not per user issues, I have a couple notes to make on the documentation.

In section 9.9 we unmount our filesystem to reboot, however /mnt/gentoo/dev was not mounted.

Also on the note of getting booted into a system running the proposed setup, which is the idea of the guide, one might not get udev to load anything. Apparently from what I've gathered and what seems to work for many others with this issue across the forums, is the emerging of the baselayout which we don't emerge in the guide. After that, udev goes about it's business perfectly and we have a nice new stable environment.

Just thought to address these two issues in the hopes to help get this guide as perfect as possible, which it is quite to being. This is my first attempt at gentoo and have only used RH9 before with many package problems. I'm loving it so far, and the support on the forums is the best I've ever seen. Thanks for spending the time on making this guide, even a damn near total idiot to linux like me has been able to use it to provide a wonderful environment using an easy install.   :Wink: 

----------

## Bob P

 *Doom0r wrote:*   

> Also on the note of getting booted into a system running the proposed setup, which is the idea of the guide, one might not get udev to load anything. Apparently from what I've gathered and what seems to work for many others with this issue across the forums, is the emerging of the baselayout which we don't emerge in the guide. After that, udev goes about it's business perfectly and we have a nice new stable environment.

 

thanks for your note about the typo in section 9.9.  that was a cut and paste error on my part.   :Embarassed: 

we've had lots of installs using this method and no reported udev failures, so i'm not so sure that there is anything to worry about.

regarding the baselayout -- you don't have to emerge it  --  its extracted from  the Stage 3 tarball!  :Exclamation:    you even recompile it when performing the emerge -e system.  a quick grep of /var/log/emerge.log will confirm this.

thanks for the feedback.    :Wink: 

----------

## rjw8703

kimchi_sg said

 *Quote:*   

> I think the onus is solely on you to make a topic in the Installation Gentoo forums (or another forum you would deem appropriate for this), expressly for testers of your installation method to voice their requests for help. 
> 
> The reason for this is that there are people who install their systems using tutorials from Documentation, Tips and Tricks (like this one) to install their systems, and then run into trouble with their install, then do as you have suggested here - post their questions to Installing Gentoo. 
> 
> But the people who frequently answer posts in Installing Gentoo may have no idea which exact D, T & C tutorial the person in trouble followed, especially since the relevant link is often the last thing they bother to include in their help request. 
> ...

 

I'am using your tut. I'm on part 8.1 of the tut. I had used the stable 

branch earlier and it worked. Athough that shouldn't be a suprise. Now

I'm using the testing branch (~x86) and ran into this problem. That's why 

I am using this forum, because there is nowhere else to turn with people

who know what I am going through. Now back to the problem at hand.

----------

## Bob P

 *rjw8703 wrote:*   

> kimchi_sg said
> 
>  *Quote:*   I think the onus is solely on you to make a topic in the Installation Gentoo forums (or another forum you would deem appropriate for this), expressly for testers of your installation method to voice their requests for help. 
> 
> The reason for this is that there are people who install their systems using tutorials from Documentation, Tips and Tricks (like this one) to install their systems, and then run into trouble with their install, then do as you have suggested here - post their questions to Installing Gentoo. 
> ...

 

That's a good joke!   :Laughing:  If kimchee_sg were my employer, I might actually have to do what you quoted him as having said.  But since he's not, if you want my help then your only hope is to take a not so subtle hint and post in one of the support forums.  Your problem is caused by an operator error and is not related to a problem in the guide.  It belongs in one of the support forums.

----------

## hielvc

Posted an updated automatic emerge wrapper for emerge updates since portage will build vour toolchain updates ass backwards .  An emerge wrapper for correctly building the toolchain

----------

## Bob P

OH YES!!!

heil, i've been meaning to post in response to that script that you posted earlier, but i've been so busy that i haven had a chance.  i think that the script that you posted before was a fantastic idea.  essentially, it follows the same steps that i go through when i manually perform a system update.  needless to say, i'm happy as a clam that you've decided to pursue this!  the automated wrapper looks fantastic.  great work!

----------

## kimchi_sg

 *rjw8703 wrote:*   

> I'am using your tut. I'm on part 8.1 of the tut. I had used the stable branch earlier and it worked. Athough that shouldn't be a suprise. Now I'm using the testing branch (~x86) and ran into this problem. That's why I am using this forum.

 

I was saying that as a strong suggestion, although Bob P does have a right not to do so.

The point is, if you have installation-related problem, do the following steps in order:Search for similar requests for help in Installing Gentoo forum.If and only if there are no similar requests, post a new topic detaling your problem.Do not assert so confidently that *rjw8703 wrote:*   

> there is nowhere else to turn with people who know what I am going through.

 A lot of developers and experienced users prowl the Installing Gentoo forum too.

----------

## hielvc

Well when I first posteda  certain minor errors like not being able to update without updateing the toolchain,TC, was left out   :Laughing:   The 1.8.5 version fixed that. Its to hard to post and watch Troy. Later

----------

## rstrom

Excellent tutorial.

However, I noticed that you have 'rc-update add ntp-client default'  twice.

First in '7.3.2 Updating the Environment' and then again in '7.3.3 Configuring the NTP Client '.

Note: 'rc-update add ntp-client default'  doesn't appear in the one liner from '7.3.2 Updating the Environment' .

----------

## Bob P

 *rstrom wrote:*   

> Excellent tutorial.
> 
> However, I noticed that you have 'rc-update add ntp-client default'  twice.
> 
> First in '7.3.2 Updating the Environment' and then again in '7.3.3 Configuring the NTP Client '.
> ...

 

thanks for the heads-up.  the rc-update line should not be present in the first part of section 7.3.2.  everything else is correct.

this error has now been corrected in the forum version of the guide.  it was not present in the PDF version.

----------

## piwacet

Finished installing... Works 100%.  Yeah.   :Cool: 

Thanks for the tutorial, it's a great asset for our community!

----------

## taskara

hey,

great idea, love it!

one question though, please

anyone checked that libc.so.6 was definately compiled with NPTL?

```
$ /lib/libc.so.6

GNU C Library 20041102 release version 2.3.4, by Roland McGrath et al.

Copyright (C) 2004 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.

There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

PARTICULAR PURPOSE.

Compiled by GNU CC version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7).

Compiled on a Linux 2.6.8 system on 2005-01-22.

Available extensions:

        GNU libio by Per Bothner

        crypt add-on version 2.1 by Michael Glad and others

        linuxthreads-0.10 by Xavier Leroy

        The C stubs add-on version 2.1.2.

        GNU Libidn by Simon Josefsson

        BIND-8.2.3-T5B

        libthread_db work sponsored by Alpha Processor Inc

        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk

Thread-local storage support included.

For bug reporting instructions, please see:

<http://www.gnu.org/software/libc/bugs.html>.

```

On my system (just followed this install method) I do NOT have nptl, but linuxthreads-0.10 (even though I have the "nptl" flag, and linux26-headers).

What do you guys have?

I think this was why the nptlonly flag was brought out.

Is there a way to switch to native posix? or does the system need re-compiling from scratch?

How should one go about rectifying this?

This is from my laptop, with nptl and gcc 3.4.3, build differently from stage 1

```
chris@josiah ~ $ /lib/libc.so.6

GNU C Library 20041102 release version 2.3.4, by Roland McGrath et al.

Copyright (C) 2004 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.

There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A

PARTICULAR PURPOSE.

Compiled by GNU CC version 3.4.3  (Gentoo Linux 3.4.3, ssp-3.4.3-0, pie-8.7.6.6).

Compiled on a Linux 2.6.8 system on 2004-12-13.

Available extensions:

        GNU libio by Per Bothner

        crypt add-on version 2.1 by Michael Glad and others

        Native POSIX Threads Library by Ulrich Drepper et al

        The C stubs add-on version 2.1.2.

        GNU Libidn by Simon Josefsson

        BIND-8.2.3-T5B

        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk

Thread-local storage support included.

For bug reporting instructions, please see:

<http://www.gnu.org/software/libc/bugs.html>.

```

Cheers!

----------

## blackwhite

 *taskara wrote:*   

> hey,
> 
> great idea, love it!
> 
> one question though, please
> ...

 

yes, I have the same result. But when you run this, you will have this:

 *Quote:*   

> p3 root # /lib/tls/libc.so.6
> 
> GNU C Library 20041102 release version 2.3.4, by Roland McGrath et al.
> 
> Copyright (C) 2004 Free Software Foundation, Inc.
> ...

 

BTW, I have trouble to compile gnome and kde. when compiling fam,  it will fails compiling with error. Does anyone have ideas about this? thanks.

----------

## taskara

a huh!

so it somehow is set to use linux threads, but can switch to use posix?

or does the library under /lib/tls override that under /lib ?

ta

p.s you might need to post the kde / gnome emerge error, but I don't think they wanna use this as a support thread..?

wait.. I did have a fam error a few months back.. have u tried later / earlier versions? I can't remember what i did to fix it.. I think I switched to an older version of somethiing, then emerged fam, then switched back.. now what was it?... *thinking*

----------

## Goliath

Hi, 

I followed this thread and the whole nptl-thing, which really seems to make a difference.

At the moment I'm reading this: http://people.redhat.com/drepper/nptl-design.pdf to understand, what it really is.

Anyway. Bob, your tutorial seems to be an installation howto. My question is: can I use nptl on an already installed system without destroying it? I'd probably have to recompile everything, because nptl is a Flag used by the gcc, right?

Can you give me more info or point me to another tutorial on applying nptl to a running gentoo installation?

All the Best,

David

----------

## NaN

Bob, Excellent guide, thanks.

There is one important thing you should add: KEYMAP setting.  :Smile: 

/etc/rc.conf should be edited with the correct KEYMAP setting before rebooting otherwise you end up with a keyboard that may be disfunctional.

At the same time I'd also suggest setting the LANG environment variable.

Otherwise the installation went flawlessly.

David.

----------

## kimchi_sg

 *Goliath wrote:*   

> Can you give me more info or point me to another tutorial on applying nptl to a running gentoo installation?

 

http://gentoo-wiki.com/HOWTO_Migrate_to_NPTL

Make sure gentoo-wiki.com is in your bookmarks if you are a true blue Gentoo user.  :Very Happy: 

----------

## blackwhite

 *taskara wrote:*   

> 
> 
> p.s you might need to post the kde / gnome emerge error, but I don't think they wanna use this as a support thread..?
> 
> wait.. I did have a fam error a few months back.. have u tried later / earlier versions? I can't remember what i did to fix it.. I think I switched to an older version of somethiing, then emerged fam, then switched back.. now what was it?... *thinking*

 

thanks reminding. But you know the problems come with this method, different with regular one,  so I just ask wheather you also have such a trouble, I will post my question on the support part.

----------

## macawgumbo

What about CFLAGS setting for AMD K6-2 (500MHz) which is an i586 processor?

----------

## Bob P

in the spirit of keeping the focus of this Guide limited to the Stage 1 on 3 installation method, i'm specifically avoiding the idea of fattening up this Guide in order to turn it into a replacement for the  Gentoo Installation Handbook.  this Guide is for advanced users, not for inexperienced users.  to that end, this Guide focuses upon how to do the Stage 1 on 3 installation, and it uses Gentoo's default locale (which happens to be my locale  :Wink: ).   i'm not going to cover things like how to install for alternate locations, how to use non-standard keyboard mapping, etc.  the result of doing that would bloat this guide to a point beyond my objectives.  

if anyone has special needs that aren't covered in this Guide, your only choice is to do your own homework and learn how to adapt this guide to your individual situation.  i am not going to rewrite this Guide so that it becomes a Universal Installation Handbook.  I just don't have the time to provide free consulting services for everyone who doesn't know how to complete their own Gentoo installation.  if this guide doesn't cut it for you, you're going to have to tackle some of the problems youself.  just post a thread in the support forums and someone with experience is sure to help you.   

on the subject of CFLAGS, this subject gets beaten to death all over the Gentoo forums.  i've specifically mentioned safe CFLAGS settings that should get you up and running.  this Guide clearly states that no support is provided for CFLAGS settings that go beyond those recommended for a basic Gentoo installation.  there is a reason for the official CFLAGS recommendations in the GIH and in this Guide.  CFLAGS that go beyond these settings aren't supported.  Period.

if you just can't live with the default CFLAGS settings and you want more architecture-specific optimization, go read the CFLAGS CEntral thread in Portage and Programming.  once you have an idea what types of CFLAGS you'd like to try, it is your responsibility to experiment with them and to assure that they will not break another ebuild somewhere farther down the line.

finally, it is very far beyond the scope of this thread to ask support questions about installing KDE, or any other application.  this Installation Guide is about installing GENTOO, not KDE.  if you need support with another program, please post about it in the appropriate support forum.

----------

## Bob P

 *taskara wrote:*   

> so it somehow is set to use linux threads, but can switch to use posix?

 

as i understand it, NPTL is the default, with fallback to linux threads if NPTL doesn't work.  if you were to use the USE="nptlonly" flag, then it would be NPTL default, with no fallback support if NPTL doesn't work.

----------

## taskara

 *Bob P wrote:*   

>  *taskara wrote:*   so it somehow is set to use linux threads, but can switch to use posix? 
> 
> as i understand it, NPTL is the default, with fallback to linux threads if NPTL doesn't work.  if you were to use the USE="nptlonly" flag, then it would be NPTL default, with no fallback support if NPTL doesn't work.

 

Thanks Bob, just wanted to clarify in case there was something missing from your guide.. which of course is highly unlikely!  :Wink:  cheers, and good work!

----------

## DrWoland

*Deleted*Last edited by DrWoland on Sun Jan 23, 2005 7:26 pm; edited 1 time in total

----------

## kimchi_sg

 *DrWoland wrote:*   

> I have discovered the following:
> 
> GCC 3.4.3-r1 compile segfaulted all over itself at first. Then, seeing as this was most likely a hardware issue and thinking of something I saw in a grub-related problem thread, I tried the following:
> 
> ```
> ...

 This post (in the NPTL from stage 1 topic) would suggest otherwise: https://forums.gentoo.org/viewtopic.php?p=1713417#1713417

But the poster was doing a bootstrap from stage 1 in knoppix though, so it may be safe to include the command here.

----------

## DrWoland

*Deleted* Am I dumb or are we not allowed to delete our own posts?Last edited by DrWoland on Sun Jan 23, 2005 7:26 pm; edited 1 time in total

----------

## Bob P

this Guide has always been intended solely as a collection of tips and tricks from advanced users for advanced users.  even though its clearly identified as such, the popularity of this installation method has spread like wildfire, such that it is widely being regarded as the de-facto method for installing Gentoo. people are currently  referencing this guide and saying that the Stage 1 installation method has been deprecated and this method is its replacement! unfortunately, nothing could be farther from the truth.   :Exclamation: 

this guide should not, by any means, be considered to be a standard or a default Gentoo installation method.  its a kludge workaround that has been developed to put a band-aid on a problem that exists in Gentoo 2004.3 that i hope will be absent when 2005.0 is released.  hopefully then this method of installation can be abandoned and this installation guide can be erased.

unfortunately, an incredibly large number of inexperienced users have adopted this guide, and placed somewhat unrealistic expectations upon it.  as a result, i have become an absolute n00b magnet.  i literally get scores of personal messages where new users are petitioning me to provide them with installation help and technical support, as if i have become some sort of cult h3r0 -- a pied-piper of the basement-dwelling linux nerds, so to speak.

please bear in mind that this Guide is a non-official/unauthorized and unsupported installation method.  it is not recommended as a standard installation method.  as such, users should expect that they may encounter problems that they will need to solve on their own, or with the assistance of the support forums.

----------

## Gullible Jones

Okay, problem here... When I try to compile from within Damn Small Linux (stripped-down Knoppix), the glibc compile checks for my kernel version and stops, saying that I need a version > 2.6.5 to compile glibc with NTPL support. 

Yes, I have unmerged linux-headers and emerged linux26-headers.

AFAIK, DSL's having the 2.4 kernel should be irrelevent.

DSL's versions of glibc and GCC shouldn't  matter either, since I'm compiling everything with the versions of glibc and GCC that come in the stage 3 2004.3 package - perfectly up-to-date versions.

Any advice?

----------

## Bob P

 *Gullible Jones wrote:*   

> Okay, problem here... When I try to compile from within Damn Small Linux (stripped-down Knoppix), the glibc compile checks for my kernel version and stops, saying that I need a version > 2.6.5 to compile glibc with NTPL support. 
> 
> Yes, I have unmerged linux-headers and emerged linux26-headers.
> 
> AFAIK, DSL's having the 2.4 kernel should be irrelevent.
> ...

 

Yes.    I would recommend all of the following for starters:

1. Read the Guide and pay attention. 

2. Follow the Guide as it is written.   

3. Install from the Gentoo CD, not DSL.  

4. Don't use a 2.4 kernel.  

5. Pay attention to the error messages that appear on screen.

6. Don't post support requests in this thread.  

I get the impression that you did not pay attention to anything that i wrote in the guide, so why should i expect that you'll listen to me now?  :Rolling Eyes: 

----------

## Gullible Jones

I payed attention to everything you wrote in the guide, except for using the Live CD. I don't have a CD burner or a floppy drive...

And sorry for asking a support question. I believe I saw others post similar things here without being reprimanded.

----------

## kimchi_sg

 *Gullible Jones wrote:*   

> I payed attention to everything you wrote in the guide, except for using the Live CD. I don't have a CD burner or a floppy drive...

 

You will need to find another linux distro that comes with kernel version greater than 2.6.5. DSL apparently does not make the cut.

 *Gullible Jones wrote:*   

> And sorry for asking a support question. I believe I saw others post similar things here without being reprimanded.

 

This is a statement that is very easy to make, but extremely hard to substantiate with obvious examples.

----------

## hielvc

ME wants em autographed PHOTO of our h3r0 before he loses his hair  :Laughing: 

----------

## kimchi_sg

 *hielvc wrote:*   

> ME wants em autographed PHOTO of our h3r0 before he loses his hair 

 

Come on, our h3r0 had this in his signature not so many months ago: *Bob P's sig wrote:*   

> I'm still a n00b, in spite of my forum ranking.

 

He can't have grown up so fast...  :Very Happy:   :Very Happy: 

----------

## Bob P

 *hielvc wrote:*   

> ME wants em autographed PHOTO of our h3r0 before he loses his hair 

 

Hah!  you are too late!  my hair all fell out shortly after i wrote this guide!   :Embarassed: 

i'm sorry that i don't have any autographed photos, so this  will have to do.  :Wink: 

kimchi_Sg, i am still a n00b, in spite of my forum ranking.  the only catch is that only the old timers really know it.   :Rolling Eyes:  

----------

## kimchi_sg

 *Bob P wrote:*   

> Hah!  you are too late!  my hair all fell out shortly after i wrote this guide!  
> 
> EDIT: Remove all the fat [color] tags that were messing up the post.

 You use of colour could / should be more discreet. It makes me wonder how you choose your colour for posts. Do you choose one to match the shirt you're wearing today? Or...Did your hair fall out as a result of the stress in answering so many newbies' support questions, due in no small part to the creation of this tutorial?  :Razz: 

 *Bob P wrote:*   

> kimchi_Sg, i am still a n00b, in spite of my forum ranking.  the only catch is that only the old timers really know it.  

 

After my post, everyone will know!  :Twisted Evil:   :Very Happy:   :Wink: 

----------

## Wonkey_Donkey

I'm a little curious about this.

I've been reading through this thread and also the one about GCC3.4/NPTL Stage 1 install.

Would it be fair to say that if I bootstrapped a system using the fairly conservative flags ie. '-march=pentium4 -O2 -fomit-frame-pointer', and then, once it had finished, change my flags to the ones mentioned in the first post of this thread and bootstrapped again, it would have the same effect as the method originally detailed here, but from a stage 1 install ?

Or can I just add nptl to my make flags, 'emerge --nodeps gcc-config gcc'  (To get gcc3.4) and then use the slightly more aggresseive flags from the start and proceed with a normal stage 1 install ?

----------

## kimchi_sg

 *Wonkey_Donkey wrote:*   

> Would it be fair to say that if I bootstrapped a system using the fairly conservative flags ie. '-march=pentium4 -O2 -fomit-frame-pointer', and then, once it had finished, change my flags to the ones mentioned in the first post of this thread and bootstrapped again, it would have the same effect as the method originally detailed here, but from a stage 1 install ?
> 
> Or can I just add nptl to my make flags, 'emerge --nodeps gcc-config gcc'  (To get gcc3.4) and then use the slightly more aggresseive flags from the start and proceed with a normal stage 1 install ?

 

No, no, no.

All 3 installation methods (NPTL from stage 3 tarball, NPTL from stage 1, and the official Handbook method) are mutually exclusive. In other words, do not mix and match steps from any of the 3 to form a "hybrid" install method. Not if you want to avoid headaches.  :Smile: 

The rule is, you stick to one and only one method, and follow it dogmatically.

----------

## Wonkey_Donkey

Ok, understood !

 :Smile: 

----------

## Gav`

 *Bob P wrote:*   

>  *taskara wrote:*   so it somehow is set to use linux threads, but can switch to use posix? 
> 
> as i understand it, NPTL is the default, with fallback to linux threads if NPTL doesn't work.  if you were to use the USE="nptlonly" flag, then it would be NPTL default, with no fallback support if NPTL doesn't work.

 Any evidence to substantiate this? I've got the same thing, and I'm concerned that since surely /lib would be the default location, NPTL isn't actually being used at all?

EDIT: On the second emerge of glibc, I just spotted the text spat out by Portage, giving me the above info (which I guess is where you got it from?). Is there any way of testing whether NPTL is in fact the default?

----------

## kimchi_sg

 *Gav` wrote:*   

> Is there any way of testing whether NPTL is in fact the default?

 

Yes. Run /lib/tls/libc.so.6, and you should see NPTL listed in the features compiled in.

----------

## Gav`

Yes, I do, but where is it specified that /lib/tls/libc.so.6 is the default? I would expect that the (more generic) /lib/libc.so.6 is the default, and any fallbacks are contained in subdirectories.

To me, the current layout would suggest that linuxthreads is the default, and NPTL is only used for applications which know where to find it.

----------

## johnsimcall

Thank you Bob P for your tutorial!  I am appreciative of the valuable time you have put into this tutorial and the subsequent revisions.  I am reminded of my introductions to Linux several years ago, and the roads I have been led down.  Reading your tutorial, rants, and raves reminded me of the mentor who introduced me to Linux and the quest for knowledge.  He sadly passed away two years ago and a great source of knowledge was lost.  I believe it is the intent of the forums and documentation projects to organize the cumulative knowledge a person acquires and to make it available to others.  I was taught and believe that the smartest person is not the one who has the most knowledge, but the one who knows how to ask the best questions.  Thank you for having made your knowledge available to the Gentoo community and guiding us to the resources that make learning possible.  I have learned a lot.

Honest accolades,

JC

----------

## kimchi_sg

 *Gav` wrote:*   

> Yes, I do, but where is it specified that /lib/tls/libc.so.6 is the default?

 

No other more authoritative source, than the glibc ebuild script itself... I suggest you open it and read it too. Very fascinating!  :Very Happy: 

```
pkg_setup() {

   if use nptlonly && use !nptl ; then

      eerror "If you want nptlonly, add nptl to your USE too ;p"

      die "nptlonly without nptl"

   fi

   # give some sort of warning about the nptl logic changes...

   if want_nptl && use !nptlonly ; then

      ewarn "Warning! Gentoo's GLIBC with NPTL enabled now behaves like the"

      ewarn "glibc from almost every other distribution out there. This means"

      ewarn "that glibc is compiled -twice-, once with linuxthreads and once"

      ewarn "with nptl. The NPTL version is installed to lib/tls and is still"

      ewarn "used by default. If you do not need nor want the linuxthreads"

      ewarn "fallback, you can disable this behavior by adding nptlonly to"

      ewarn "USE to save yourself some compile time."

      ebeep

      epause

   fi

}
```

----------

## DrWoland

 *kimchi_sg wrote:*   

> USE THESE CFLAGS AT YOUR OWN RISK
> 
> The first set of CFLAGS I used (from "emerge -C linux-headers" to "emerge gcc-config glibc binutils gcc"): 
> 
> ```
> ...

 

Currently re-compiling the toolchain with these flags  :Shocked:  Can't believe they've worked this far. I wish I could just get the itch out of my ass and stop re-installing. Oh yeah, I'm also using a RR4 livecd, trying this guide with Reiser4  :Shocked:  If this comes through, I'm gonna have one monster ass system!!!W

Edit: It worked   :Shocked:  Got to the point of xorg starting with the nvidia driver too, no problems except for a dumb segfault which was taken care of by re-emerging libtools.

----------

## Bob P

 *johnsimcall wrote:*   

> Thank you Bob P for your tutorial!  I am appreciative of the valuable time you have put into this tutorial and the subsequent revisions.  I am reminded of my introductions to Linux several years ago, and the roads I have been led down.  Reading your tutorial, rants, and raves reminded me of the mentor who introduced me to Linux and the quest for knowledge.  He sadly passed away two years ago and a great source of knowledge was lost.  I believe it is the intent of the forums and documentation projects to organize the cumulative knowledge a person acquires and to make it available to others.  I was taught and believe that the smartest person is not the one who has the most knowledge, but the one who knows how to ask the best questions.  Thank you for having made your knowledge available to the Gentoo community and guiding us to the resources that make learning possible.  I have learned a lot.
> 
> Honest accolades,
> 
> JC

 

JC, thanks for the kind words.    :Very Happy: 

i'm glad to hear that someone appreciates all of the work that it has taken to put the guide together, and bothers to take the time to write a sincere note about it. (on your first post!) i've lost my own teacher as well, and i know how you feel.  every time that i've learned something new, i wish that i had the chance to talk to him about it.

in reading your note, i get the impression that you're one of the guys who really understands what the guide is really about... that you're not one of the guys who is just blindly following the directions and getting the desired results.  i hope that i'm right in making that assumption, as its much more satisfying to encounter a few people who really understand why i'm trying to do things the way i'm trying to do them.  :Wink: 

thanks again for your kind words, and welcome to Gentoo!

----------

## Bob P

 *DrWoland wrote:*   

> Currently re-compiling the toolchain with these flags  Can't believe they've worked this far. I wish I could just get the itch out of my ass and stop re-installing. Oh yeah, I'm also using a RR4 livecd, trying this guide with Reiser4  If this comes through, I'm gonna have one monster ass system!!!W
> 
> Edit: It worked   Got to the point of xorg starting with the nvidia driver too, no problems except for a dumb segfault which was taken care of by re-emerging libtools.

 

Doc, it sounds like you're turning into a Gentoo Ricer.   :Shocked: 

I'd guess that by now you would be tired of compiling, but if you've become obsessed with it, I have some CFLAGS that you may be interested in.  I've been reluctant to post them here, because I'm sure that somebody will try to use them and run into problems.  These are the flags that I used to complete the Stage 1 on 3 install on one of my testbeds (without any problems):

```
CHOST="i686-pc-linux-gnu"

# (choose optimization level)

CFLAGS="${CFLAGS} -O3"

#CFLAGS="${CFLAGS} -O2"

# (use these only if -O2, they are included in -O3)

#CFLAGS="${CFLAGS} -fweb"

#CFLAGS="${CFLAGS} -frename-registers"

# (choose additional flags as appropriate)

CFLAGS="${CFLAGS} -march=pentium3 -pipe"

CFLAGS="${CFLAGS} -mtune=pentium3"

CFLAGS="${CFLAGS} -fforce-addr"

CFLAGS="${CFLAGS} -momit-leaf-frame-pointer"

CFLAGS="${CFLAGS} -fomit-frame-pointer"

CFLAGS="${CFLAGS} -ftracer"

# (optional CFLAGS suggested by kimchi_sg)

CFLAGS="${CFLAGS} -funroll-loops"

CFLAGS="${CFLAGS} -falign-functions"

CFLAGS="${CFLAGS} -fmerge-all-constants"

CFLAGS="${CFLAGS} -mfpmath=sse"

CFLAGS="${CFLAGS} -maccumulate-outgoing-args"

CFLAGS="${CFLAGS} -fprefetch-loop-arrays"

# (CXXFLAGS: choose one)

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

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

#CXXFLAGS="${CFLAGS}"

```

essentially, these CFLAGS are just a combination of my CFLAGS that i had posted in the original version of this guide, concatenated with those suggested by kimchi_sg.  much to my surprise, the combined flags compiled on my testbed without a hitch.

you'll notice that i've "stacked" my CFLAGS, so that each line that is not commented out in make.conf becomes appended to the line that preceeded it.  i did this to make troubleshooting easy, just in case i ran into CFLAG problems and needed to trim some of them out.  much to my amazement, i got all of the way through the system installation without any packages borking -- even when building a PC in the testing branch.   :Shocked:   the only time that i had to change them was to accomodate KDE, and IIRC all that I had to do was to remove the usual suspect:  -fvisibility=hidden.

i had been thinking for quite some time about posting something about nested CFLAGS to this thread.  although i hadn't used this technique when i was doing my initial Stage 1 on 3 installs or when i was writing the Guide, i noticed someone else using this technique on one of the other threads.  (i wish i could remember who to give the credit to!)  the really nice thing about nested CFLAGS statements is that they are very readable, and if you should run into an ebuild that borks on a CFLAG, its very simple to quickly edit make.conf, recompile, re-edit to restore your CFLAGS, and get back to business.  its a writing technique that some users may find very useful, and i hope that it helps.   :Wink:  

----------

## DrWoland

 *Bob P wrote:*   

>  *DrWoland wrote:*   Currently re-compiling the toolchain with these flags  Can't believe they've worked this far. I wish I could just get the itch out of my ass and stop re-installing. Oh yeah, I'm also using a RR4 livecd, trying this guide with Reiser4  If this comes through, I'm gonna have one monster ass system!!!W
> 
> Edit: It worked   Got to the point of xorg starting with the nvidia driver too, no problems except for a dumb segfault which was taken care of by re-emerging libtools. 
> 
> Doc, it sounds like you're turning into a Gentoo Ricer.  
> ...

 

Crap, that is hot! However, I'm fairly certain all of the flags listed were already used by me  :Shocked: 

Edit: Bob, did you get my PM about this? Not all of it is about this, read the last paragraph or two and tell me what you think. If you didn't get it because your pm box is overflowing with noobs, pm me your e-mail so I can drop you a note. Thanks.

Mikhail

----------

## kimchi_sg

Reporting my latest successful install using this method. It was done using the slowest machine I've ever installed gentoo on. (but then i've only installed it on 3 PCs so far.  :Razz:  )

Specs: IBM Thinkpad T20, 128MB RAM, Pentium 3 coppermine with speedstep, 12GB hard drive

It performs reasonably well, after installing KDE 3.4.0 split ebuilds. Almost like a pentium 4!  :Smile: 

----------

## Zepp

I think I may try and give this method a shot in the next day or so. Off for rest of week till new semester starts so got some spare time.

----------

## Bob P

 *kimchi_sg wrote:*   

> Reporting my latest successful install using this method. It was done using the slowest machine I've ever installed gentoo on. (but then i've only installed it on 3 PCs so far.  )
> 
> Specs: IBM Thinkpad T20, 128MB RAM, Pentium 3 Coppermine with speedstep, 12GB hard drive
> 
> It performs reasonably well, after installing KDE 3.4.0 split ebuilds. Almost like a pentium 4! 

 

Hehe.  Its funny that you're reporting your latest successful install on the slowest machine you've ever installed Gentoo on, a Pentium 3 Coppermine!

It turns out that a P3-800 Coppermine is my standard desktop box, and the fastest machine that I've ever installed Gentoo on!  Even when running KDE, my P3-800 with 256 MB feels plenty fast after the Stage 1 on 3 installation -- fast enough that I feel no need whatsoever to upgrade to a Pentium 4.  (granted, it may not feel like the fastest PC on the block when its comes time to emerge -e world, but as a desktop box, a Coppermine running Gentoo/KDE feels plenty fast.   :Wink: 

----------

## DrWoland

 *Bob P wrote:*   

>  *kimchi_sg wrote:*   Reporting my latest successful install using this method. It was done using the slowest machine I've ever installed gentoo on. (but then i've only installed it on 3 PCs so far.  )
> 
> Specs: IBM Thinkpad T20, 128MB RAM, Pentium 3 Coppermine with speedstep, 12GB hard drive
> 
> It performs reasonably well, after installing KDE 3.4.0 split ebuilds. Almost like a pentium 4!  
> ...

 

 Answer my PM.  :Evil or Very Mad: 

----------

## LordBug

I got hung up for a day due to the gcc 3.4.3-r1 bug, but I now have this build method 95% complete.  Bootstrap is finished, kernel tree is downloaded (but not yet compiled), and Xorg is compiling now (since I'm at work, I'll let that go all day). 

I ended up having to do this whole thing using a 2005.0 beta CD, as the system has SCSI, and 2004.3 hangs with the 'doscsi' command.  It all went off without a problem (save for GCC, but that's not the Guide's fault).

----------

## Bob P

 *LordBug wrote:*   

> I now have this build method 95% complete.  Bootstrap is finished, kernel tree is downloaded (but not yet compiled), and Xorg is compiling now (since I'm at work, I'll let that go all day).

 

thanks for the feedback.  i'm kinda confused by your post, as there is no bootstrap in this guide.  btw, if you're compiling xorg, you must have successfully finished the gentoo  installaton.    :Smile: 

thanks for letting us know that the guide works well with the 2005.0 beta CD.   :Wink: 

by any chance, does anyone know what version of GCC is being used to produce the 2005.0 beta CD?

----------

## kimchi_sg

 *Bob P wrote:*   

> Hehe.  Its funny that you're reporting your latest successful install on the slowest machine you've ever installed Gentoo on, a Pentium 3 Coppermine!
> 
> It turns out that a P3-800 Coppermine is my standard desktop box, and the fastest machine that I've ever installed Gentoo on!  Even when running KDE, my P3-800 with 256 MB feels plenty fast after the Stage 1 on 3 installation -- fast enough that I feel no need whatsoever to upgrade to a Pentium 4.  (granted, it may not feel like the fastest PC on the block when its comes time to emerge -e world, but as a desktop box, a Coppermine running Gentoo/KDE feels plenty fast.  

 

Mine is a "mobile" coppermine 700mHz with just 128MB RAM. Maybe that will explain the difference. Could it be the speedstep technology kicking in automatically? I'm plugged in to AC 100% of the time while installing, though.  :Very Happy: 

----------

## addeman

removed textLast edited by addeman on Sun Feb 06, 2005 8:49 pm; edited 2 times in total

----------

## kimchi_sg

Removed.

----------

## addeman

Removed text...Last edited by addeman on Sun Feb 06, 2005 8:48 pm; edited 1 time in total

----------

## Bob P

in the interest of keeping irrelevant material out of this thread, i'd like to ask everyone who's posted a support request that has been solved to remove the associated text from their post.  this will remove some of the unnecessary bloat, making it easier for people who are trying wade through all of the irrelevant material on this thread while trying to learn about Stage 1 on 3 installations.

thanks.

kimchi, you might want to check "cat /proc/cpuinfo" to see how many bogomips you're getting out of that mobile p-3.  a desktop p3-800 has a value of 1573.

----------

## Zepp

I completed the guide but had a problem with sysfs not mounting and then root failing... 

Apparently I need more recent versions of several packages, which i had to add to package.keywords

my problem here:

https://forums.gentoo.org/viewtopic.php?p=2063414#2063414

solution found here:

https://forums.gentoo.org/viewtopic.php?t=277502

had to add the following to packages.keywords

```
app-shells/bash ~x86

sys-fs/udev ~x86

sys-fs/sysfsutils ~x86

sys-apps/baselayout ~x86

sys-libs/readline ~x86

sys-apps/sysvinit ~x86 
```

----------

## kimchi_sg

 *Zepp wrote:*   

> had to add the following to packages.keywords
> 
> ```
> app-shells/bash ~x86
> 
> ...

 

Yay! ACCEPT_KEYWORDS="~x86" proves its superiority again!

@Bob P: I have used ~x86 for this tutorial everytime, and failed only once, on the linux26-headers bug.  :Razz: 

----------

## busfahrer

I know there is a special thread for discussing CFLAGS, but since this thread is partly about the benefits gained from gcc-3.4.x, I wanted to ask:

On AMD64, what CFLAGS have proven to be usable for you people with this installation method (or in general)?

Sorry if it doesn't fit in 100%.

----------

## evapilot

Doesn't GCC compile itself? This can be shown if you use -mcpu in the first toolkit compile, because it fails half way through with a warning to change to mtune.

Also, I think it's best to put the optimized CFLAGS after the initial toolkit recompilation, as emerge -e system will cause it to recompile anyway.

----------

## DrWoland

 *evapilot wrote:*   

> Doesn't GCC compile itself? This can be shown if you use -mcpu in the first toolkit compile, because it fails half way through with a warning to change to mtune.
> 
> Also, I think it's best to put the optimized CFLAGS after the initial toolkit recompilation, as emerge -e system will cause it to recompile anyway.

 

You did something wrong, I got no such failure. Start over, the compiler shouldn't change to 3.4.3 until you run "gcc-config 2" AFTER the first toolkit compile. Even after 3.4.3 is on your system, you can go back to 3.3.4 at any time by running gcc-config 1. Hope that helps. Try running gcc-config -l to see what compiler is currently being used, that is if gcc-config already compiled. Seriously though, like I said, sounds like you butchered something.

----------

## kimchi_sg

 *evapilot wrote:*   

> Also, I think it's best to put the optimized CFLAGS after the initial toolkit recompilation, as emerge -e system will cause it to recompile anyway.

 

I think you have misread the tutorial there. The make.conf is edited after the "initial toolchain compilation", and the "optimized CFLAGS" are inserted only at that point. Thus, what you say is already the prescribed practice.

----------

## SaFrOuT

i have a small question and believe me i am asking it cause i can't find another solution 

i have already the CD minimal-2004.3 but NOT the r1, can i use it with this guide or it will cause problems

i am asking this cause i won't be able to get teh r1 version before 2 days and i can't wait till then to start Gentoo again

sorry for bothering

----------

## DrWoland

 *SaFrOuT wrote:*   

> i have a small question and believe me i am asking it cause i can't find another solution 
> 
> i have already the CD minimal-2004.3 but NOT the r1, can i use it with this guide or it will cause problems
> 
> i am asking this cause i won't be able to get teh r1 version before 2 days and i can't wait till then to start Gentoo again
> ...

 

Although you ARE deviating from the guide, for which punishment IS hell, I don't see why a slightly older CD won't work - as long as it gets you booted and connected. You download everything from the internet.

----------

## evapilot

Let me clarify:

Let's take step 7.2.1:

 *Quote:*   

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

 At the second part of step 7.2.4 we do 

```
emerge -e system

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

Calculating system dependencies ...done!

[ebuild  N    ] sys-devel/binutils-2.15.92.0.2-r1

[ebuild  N    ] sys-devel/gcc-3.4.3.20050110

[ebuild  N    ] sys-libs/libstdc++-v3-3.3.4

[ebuild  N    ] sys-libs/glibc-2.3.4.20041102

```

It seems to me that the optimizations should go after we do

```
emerge glibc binutils gcc portage
```

Secondly, GCC compiles itself. I.e., when we build GCC 3.4 for the first time, it builds a bootstrap 3.4 compiler, which in turn rebuilds itself - so we immediately get a GCC 3.4 built with GCC 3.4.

If you did what I did, which was to download a pentium3 stage 3 tar ball and use the default CFLAGS, which include -mcpu=pentium3, the GCC ebuild then borks when the bootstrap 3.4 compiler runs. This is because it spits out the warning about mcpu being deprecated.

On this basis, I would do the following:

1. Set basic CFLAGS for compiling speed.

2.

```
# env-update && source /etc/profile && emerge -C linux-headers && emerge linux26-headers && emerge gcc-config glibc binutils gcc && gcc-config 2 && emerge env-update && source /etc/profile && emerge glibc binutils portage
```

3. Modify the CFLAGS

4.

```
emerge -e system
```

----------

## Bob P

 *busfahrer wrote:*   

> I know there is a special thread for discussing CFLAGS, but since this thread is partly about the benefits gained from gcc-3.4.x, I wanted to ask:
> 
> On AMD64, what CFLAGS have proven to be usable for you people with this installation method (or in general)?

 

i've just picked up an AMD64 system and once i have it ready for a gentoo installation, I'll be looking at the CFLAGS and GCC 3.4 threads for the answer.   i hate to state the obvious, but looking there is really our best bet.  :Wink: 

----------

## Bob P

 *SaFrOuT wrote:*   

> i have a small question and believe me i am asking it cause i can't find another solution 
> 
> i have already the CD minimal-2004.3 but NOT the r1, can i use it with this guide or it will cause problems.

 

i would not use installation media that is older than that required for this installation method.  you need to have the right version of the Stage 3 Tarball, or you should expect that the installation will break.

----------

## kimchi_sg

 *evapilot wrote:*   

> I would do the following:
> 
> Set basic CFLAGS for compiling speed.
> 
> ```
> ...

 

I do not see what the difference is, other than sticking the CFLAGS in at a later point in time. Sooner or later you will have to change your CFLAGS, and you are just advising to do it later.

In the prescribed method, the toolchain will get rebuilt 3 times in all, once with "old' CFLAGS and twice with the "new" CFLAGS. (Excluding the internal self-rebuild gcc does each time it emerges.) Won't it be better for system stability if we keep it this way?

The new method would be a recipe for self-punishment. You build the toolchain with the new set of CFLAGS just once, running the risk that it may not be as rock-solid as building it twice upon the same set of CFLAGS. And stability is the keyword in this install tutorial.  :Wink: 

If you are just looking to dodge bug 80211, take -mcpu out of your "old" CFLAGS (the set used up to the "updating make.conf" and the gcc-config 2 command parts). No need to shuffle the order of the installation procedure.

----------

## kimchi_sg

 *Bob P wrote:*   

> i would not use installation media that is older than that required for this installation method.  you need to have the right version of the Stage 3 Tarball, or you should expect that the installation will break.

 

I oppose you on this point.

/me clutches tightly his trusty 2004.3 minimal liveCD.   :Laughing: 

----------

## SaFrOuT

 *Bob P wrote:*   

> 
> 
> i would not use installation media that is older than that required for this installation method.  you need to have the right version of the Stage 3 Tarball, or you should expect that the installation will break.

 

Ok thanks, i think i'll wait till i can get the r1 version

----------

## Bob P

 *kimchi_sg wrote:*   

>  *Bob P wrote:*   i would not use installation media that is older than that required for this installation method.  you need to have the right version of the Stage 3 Tarball, or you should expect that the installation will break. 
> 
> I oppose you on this point.
> 
> /me clutches tightly his trusty 2004.3 minimal liveCD.  

 

its about fault tolerance.  the guide is specifically written based on a series of test installations that were performed with a specific release of the gentoo minimal CD.  if you go substututing an earlier release of the gentoo minimal CD in its place without testing it, you do so in the hope that nothing will break.  that is an assumption that i am not willing to make -- potentially at someone else's expense.

that alternative installation medium referenced earlier is untested, is unproofed, and is unsupported by the guide.  like you've said before, you need to pick an installation method and follow it dogmatically.  changing installation media to something other than what has been tested amounts to asking for trouble.  if it should turn out that the alternative media works well, you get lucky.  if it turns out that the alternative installation media doesn't work well, you've wasted an awful lot of time -- much more than it would have taken to just download the right .ISO image in the first place.

the correct .ISO image is only 50 MB.  that's a small download in the realm of gentoo downloads.  in my opinion, it is better to recommend a tried and true technique than it is to speculate when giving someone advice.

----------

## Bob P

 *kimchi_sg wrote:*   

>  *evapilot wrote:*   ...if you use -mcpu in the first toolkit compile, ...it fails half way through with a warning to change to mtune. 
> 
> @Bob P: How about taking -mcpu out of the CFLAGS altogether? This is not the first time I've seen CFLAGS="-mcpu..." b0rk the gcc 3.4.3 emerge.

 

I see absolutely no need to worry about removing CFLAGS="-mcpu=<whatever>", as it does not exist anywhere in this Guide.    :Wink:  

as far as modifying the CFLAGS goes, there seems to be a recurring theme wherein less experienced users like to recommend emasculating the installation method by taking shortcuts in the interest of finishing the installation quickly.  (unfortunately, the other guy that recommended such a course of action got embarassed and erased his post, so there isn't much reference material remaining in this thread about the subject).

the people who recommend speedier installation methods  don't seem to fully appreciate the virtues of building fault-tolerance into the system via redundant compilation.  IME it is absolutely false economy to trade off fault-tolerance in order to speed-up the installation.  

if anyone is especially interested in the pursuit of such gains in speed and economy, my recommendation would be to do what i did -- devise your proposed method of installing gentoo, and then perform test installations on a heterogeneous group of computers.  then report back to us when you've developed a fault-tolerant installation method that is better than what is currently available.  then start a thread in this forum and let a few other people alpha test your installation method.  when you've achieved a high degree of success, you'll know that you're onto something.  in the interim, if your proposed changes result in b0rkage halfway through a GCC compilation, consider that it may be a sign that the idea may not have been well-conceived.  :Idea: 

----------

## thebigslide

Well put, Bob, I completely agree.

----------

## SaFrOuT

now gcc-3.5 is the main gcc in the ~x86 section

shall i use it or stick to gcc-3.4 ????

i am installing gentoo now using this guide and i don't know what shall i do

----------

## thebigslide

That would be an intersting thread to create, but this thread is about Bob P's method, I believe.  gcc 3.5 is too new for me, because some packages may not have been tested thoroughly with any given release.  Maybe I'd try it on a box where downtime is not such a big deal.  Bob P's method using gcc 3.4.3-r1 has had good success with me (3 different boxes).  This thread is in my bookmarks.

----------

## SaFrOuT

so r u saying to stick to gcc-3.4?

----------

## kimchi_sg

Yes.

If you are planning to use this installation method, stick to it 100% and do not deviate from it in any way, from start to reboot.

----------

## SaFrOuT

sorry for bothering but now emerge want to install gcc-3.4.3-20050110 not the r1 version

should i let it do so or should i stick  to the r1 version ?

edit: i used gcc-3.4.3-r1 anyway and added the 20050110 version to package.mask

----------

## Arainach

I'm in the middle of completely re-doing my system with reiserfs and this guide (As opposed to ext3 and my old Stage1), and I have the same issue.  I've heard too many scary things about 3.4.3.20050110 (even though there's an apparent speed boost) to try it, so I'm hard masking it and sticking to 3.4.3-r1.  Unfortunatley, by the time I noticed which version was compiling, it was done, so I had to unmerge it and now re-emerge gcc-3.4.3-r1.  Oh well.

----------

## Arainach

Also: Is there any particular reason that gcc-config is not re-emerged in step 7.2.4?  I've been following the guide to the letter and so left it out, but it would seem to make sense to rebuild it with the rest of the toolkit.  Is this a mistake, or is there a valid reason for it?

----------

## SaFrOuT

i think cause it is by default is re-emerged when doing emerge -e system 

and it was re-emerged with the toolkit cause gcc-config won't be used in building the system as gcc or glibc but it is only used for changing bet. gcc version so re-emerging it for 2 times won't give any better per.

----------

## thebigslide

Bob, would it make sense to add a line:

```
echo '>sys-devel/gcc-3.4.3-r1' >> /etc/portage/package.mask'
```

 to the howto?  It implies the answer to the above question.  Just a thought.

----------

## DrWoland

Every time I read this thread, I'm tempted to just re-install. MUST RESIST.

----------

## kimchi_sg

 *DrWoland wrote:*   

> Every time I read this thread, I'm tempted to just re-install. MUST RESIST.

 

Give it up, your system will thank you for making it run faster.  :Razz: 

----------

## DrWoland

 *kimchi_sg wrote:*   

>  *DrWoland wrote:*   Every time I read this thread, I'm tempted to just re-install. MUST RESIST. 
> 
> Give it up, your system will thank you for making it run faster. 

 

Ehhh It's pretty damn fast now man. I don't think anything's been significantly upgraded since my last install (2 weeks ago), so I'm just gonna wait probably till May, when school gets out, to start trying new stuff again.

----------

## kimchi_sg

 *DrWoland wrote:*   

>  *kimchi_sg wrote:*    *DrWoland wrote:*   Every time I read this thread, I'm tempted to just re-install. MUST RESIST. 
> 
> Give it up, your system will thank you for making it run faster.  
> 
> Ehhh It's pretty damn fast now man. I don't think anything's been significantly upgraded since my last install (2 weeks ago), so I'm just gonna wait probably till May, when school gets out, to start trying new stuff again.

 

Go put your system on edge...

Try out emerge world with the CFLAGS I posted here

Set ACCEPT_KEYWORDS="~x86" and then emerge -uDv --newuse world

----------

## Arainach

I must admit, this guide is AMAZING.  I had been using a regular Stage1 gcc 3.3.5 system before, and after completing this guide, I sat down, emerged X.org, and just about choked when it finished in about half an hour.  The system is RIDICULOUSLY faster.

----------

## Lucifeer

Im currently running this type of installation on my 1.2ghz Celeron laptop and the only problem I had was when re-emerging libdc++ during the "emerge -e system"-step, for some reason it refused to be compiled and gave me an error. Switching to gcc-3.3.4 for this package and abusing emerge --resume to switch to gcc-3.3.4 with gcc-config for this package was the workaround for me...

It's still not 100% done with "emerge -e system" but all other packages seams to compile fine with gcc-3.4.3

Wonder if that package will create future problems now =/ Oh well all I can do is wait

----------

## Arainach

Lucifer: Be sure that you're using gcc-3.4.3-r1, not gcc-3.4.3.20050110.  20050110 has many problems with compiling various projects, and is now the default for ~x86 if you don't manually mask it in /etc/portage/package.mask.  You'll have problems down the road if you don't change that now.

----------

## SaFrOuT

as mentioned before this guide is really 100% AMAZING

i just finsihed installing Gentoo few hours ago using it  and emerged Xorg also and gonna emerge the rest tonight will sleeping

again and again and again THANKS a lot Bob P for this wonderful and clean guide and please keep it up2date for every new gentoo user or re-installer to be able to use it  :Smile: 

thanks again  :Smile: 

----------

## DrWoland

 *kimchi_sg wrote:*   

>  *DrWoland wrote:*    *kimchi_sg wrote:*    *DrWoland wrote:*   Every time I read this thread, I'm tempted to just re-install. MUST RESIST. 
> 
> Give it up, your system will thank you for making it run faster.  
> 
> Ehhh It's pretty damn fast now man. I don't think anything's been significantly upgraded since my last install (2 weeks ago), so I'm just gonna wait probably till May, when school gets out, to start trying new stuff again. 
> ...

 

Already using your CFLAGS  :Wink:  except the packages that refuse to compile with them. Don't wanna do ~x86 because I use this computer for school and can't afford to have it out of commission at random. 

It's plenty fast enough for me, since I did this install on Resier4 as well.

----------

## Lucifeer

 *Arainach wrote:*   

> Lucifer: Be sure that you're using gcc-3.4.3-r1, not gcc-3.4.3.20050110.  20050110 has many problems with compiling various projects, and is now the default for ~x86 if you don't manually mask it in /etc/portage/package.mask.  You'll have problems down the road if you don't change that now.

  damn gcc-3.4.3.20050110 is exactly the version I have. This should be noted in the guide  :Smile: 

Sigh and I who thought I would be done with this soon =/Last edited by Lucifeer on Sun Feb 13, 2005 8:59 pm; edited 1 time in total

----------

## DrWoland

 *Lucifeer wrote:*   

>  *Arainach wrote:*   Lucifer: Be sure that you're using gcc-3.4.3-r1, not gcc-3.4.3.20050110.  20050110 has many problems with compiling various projects, and is now the default for ~x86 if you don't manually mask it in /etc/portage/package.mask.  You'll have problems down the road if you don't change that now.  damn gcc-3.4.3.20050110 is exactly the version I have. This should be noted in the guide 

 

Yeah I'm probably waiting for 3.5 or at lesat like 3.4.5 to upgrade my toolchain.

----------

## Arainach

 *Lucifeer wrote:*   

>  *Arainach wrote:*   Lucifer: Be sure that you're using gcc-3.4.3-r1, not gcc-3.4.3.20050110.  20050110 has many problems with compiling various projects, and is now the default for ~x86 if you don't manually mask it in /etc/portage/package.mask.  You'll have problems down the road if you don't change that now.  damn gcc-3.4.3.20050110 is exactly the version I have. This should be noted in the guide 
> 
> Sigh and I who thought I would be done with this soon =/

 I did the same thing; I got done compiling gcc when I noted the odd date flag, and sure enough I had the wrong version.  20050110 was hard masked for a LONG time; IMHO it still should be.

----------

## Lucifeer

So a recompile of gcc-3.4.3 thru gcc-3.3.4 and then a emerge -e system would be enough? or would I need another day to begin from scratch?  :Sad: 

----------

## Bob P

 *SaFrOuT wrote:*   

> as mentioned before this guide is really 100% AMAZING
> 
> ...
> 
> again and again and again THANKS a lot Bob P for this wonderful and clean guide and please keep it up2date for every new gentoo user or re-installer to be able to use it  (emphasis added)

 

i'm very glad to hear that everyone has enjoyed this installation method so much.   :Cool: 

regarding me keeping the guide up to date for the benefit of new gentoo users:  No -- Its not going to happen.   :Crying or Very sad: 

this Guide is not a step by step installation handbook for new users.  it has never been intended to be that, and it will never be intended to be that -- even though some people are looking at it that way now.

this Guide comprises a conceptual basis for how to build a clean, fast, and robust Gentoo installation, including detailed instructions on how to properly build a system toolkit using a specific set of packages.  no support is provided beyond what has been written into the guide.  its a fact of life that gentoo is going to change.  anyone who reads this guide and understands the underlying concepts shouldn't have any problem adapting it to Gentoo as packages are updated.   :Idea:    those who read this guide and don't understand the underlying concepts well enough to apply them should probably use one of the traditional installation methods.

if you're one of the people who understand the guide and you think that package masking is necessary, then its something that you should try.  if you find an updated package that is newer than the ones used in this tutorial, try it.  if it works, then report back to us.  if it fails, then try another approach.  ultimately, the end user who uses this installation method is responsible for his own system, regardless of whether he decides to use the stable branch or the testing branch, or whether he decides to use the actual packages that i used when i wrote the Guide, or newer packages that have since replaced them.

i think that some of you guys are seriously mis-guided when you expect that anyone has the resources to undertake some kind of everlasting commitment to keep this guide as current as the portage tree.  from a practical standpoint, what you ask is not humanly possible.  to keep the guide continually up to date, somebody would have to be performing test installations on multiple PCs every time that the portage tree is updated.  the impossible nature of that task should not be lost on anyone. 

instead of expecting to be spoonfed as every package is updated, my recommendation to the user would be to read the guide, assimilate its underlying concepts, and apply them to your situation.  its not my job to  continuously update this document -- rather, it is your job to learn the lesson that i am teaching, to climb to an admittely low plane of enlightenment, and to apply what you have learned.   :Wink: 

with that in mind, YES, i will occasionally update this guide, but because i have other commitments, i won't be updating it often enough to keep everyone happy.  :Confused:  

PS - those of you interested in GCC 3.4.3.2005<whatever> should check out this thread:

https://forums.gentoo.org/viewtopic-t-283801.html

Edit:  typos

----------

## Arainach

That would certainly work, but to get the full benefit, you'd have to re-emerge gcc-3.4.3-r1 with gcc-3.3.4 (or 3.4.3.20050110 if it can build it, but I don't think that it can) and then rebuild your entire toolkit with gcc-3.4.3-r1 before doing the emerge -e system.  Yes, it's long.  But I can now safely say that it's definatley worth it.

----------

## Bob P

 *thebigslide wrote:*   

> Bob, would it make sense to add a line:
> 
> ```
> echo '>sys-devel/gcc-3.4.3-r1' >> /etc/portage/package.mask'
> ```
> ...

 

it depends what you're trying to accomplish.  adding 3.4.3-r1 to package.mask is going to prevent you from using that package. adding 3.4.3.20050110 to the package mask might get you closer if your objective is to use 3.4.3-r1 and not use 20050110.  the problem with package masking approaches like this is that they become a real PITA.

i'm just wondering -- in your example, were you trying to facilitate the use of 3.4.3-r1 and avoid the use of 20050110?  if you're trying to do that, a better method would be to provide the desired version in the package.keywords file.  consider this example from the GIH -- i feel kind of silly posting this, as i'm sure that everyone has already RTFM and should already be familiar with it:  :Wink:  

 *Gentoo Installation Handbook wrote:*   

> Test Particular Versions
> 
> If you want to use a specific software version from the testing branch but you don't want Portage to use the testing branch for subsequent versions, you can add in the version in the package.keywords file. In this case you must use the = operator. You can also enter a version range using the <=, <, > or >= operators.
> 
> In any case, if you add version information, you must use an operator. If you leave out version information, you cannot use an operator.
> ...

 

ultimately, the decision of whether or not to use a particular verison of GCC from the testing branch or the latest version of GCC in the testing branch is a decision that the individual user has to make, based upon their review of the current GCC-related threads in the forum.  this isn't a decision that the guide is going to make on your behalf.  if you're  comfortable using the most current version of GCC provided in the testing branch, then use the guide as it is written.  if you're not comfortable using the most current version of GCC provided in the testing branch, then it should be clear how to configure portage to use a particular version that you want to use.

just for reference:  my stable branch systems are using GCC 3.4.3-r1, while my testing branch systems are using  GCC 3.4.3.20050110.  none of them have had any problems with any of the software i've installed on them.  YMMV.  

somebody sent me a PM asking where my "packages.provided" file was in the guide.  :Wink:   would anyone care to answer that one for the class?   :Idea:  

----------

## kimchi_sg

 *Bob P wrote:*   

> somebody sent me a PM asking where my "packages.provided" file was in the guide.   would anyone care to answer that one for the class?   

 

packages.provided? What is that for?  :Razz: 

It's not listed as one of the user-configurable files under /etc/portage in the Portage docs.

P.S. And this happens to be my first post in this topic as veteran.  :Very Happy: 

----------

## DrWoland

 *kimchi_sg wrote:*   

>  *Bob P wrote:*   somebody sent me a PM asking where my "packages.provided" file was in the guide.   would anyone care to answer that one for the class?    
> 
> packages.provided? What is that for? 
> 
> It's not listed as one of the user-configurable files under /etc/portage in the Portage docs.
> ...

 

Congrats, kimchi  :Cool: 

----------

## thebigslide

 *Bob P wrote:*   

>  *thebigslide wrote:*   Bob, would it make sense to add a line:
> 
> ```
> echo '>sys-devel/gcc-3.4.3-r1' >> /etc/portage/package.mask'
> ```
> ...

 

Yes.  There is no =.

----------

## Bob P

 *Quote:*   

> yes.  there is no =.

 

D'Oh!   :Embarassed:   i should have read that ">" more closely.

as your post and the "packages.provided" question shows us, there are more ways than one to skin a cat.   :Twisted Evil: 

you can use the masking method that you've mentioned, but it involves editing two different portage files to enable a single version of GCC;  you have to edit package keywords to enable gcc in the testing branch, and then you have to edit package.mask to mask subsequent versions.  IMHO, this amounts to doing things the hard way.  when i do this sort of thing, i try to modify the smallest number of config files, because -- my memory being what it is -- when its time to undo something, i won't remember to modify one of the files and something will get buggered-up.  :Embarassed: 

in contrast, if you stick with the package.keywords approach, you only have to modify a single file.   :Wink: 

feel free to do it whichever way you like -- either method should work fine.  :Cool:  

----------

## Zuti

A brief summary:

I have an AMD 2400+ XP. Gentoo I use was installed almost year ago (I think it was 2004.0, not sure).

Every now and then when i wanted to upgrade glibc/gcc I used the method of emerging system twice and then emerge -e world.

I always used CFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe" .

Well, after reading Bobs guideline I couldn't resist so I upgraded to 3.4.3 and changed my CFLAGS to those Bob recommended (I changed pentium for athlon).

I dont use ~x86 for my packages (only for toolchain related things in package.keywords, described in Bobs manual).

Now I read gcc-3.4.3.20050110 has some issues and that gcc-3.4.3-r1 should work better (faster?). I dont have any prob's and everything works great.

My questions are:

- what are the specific probs you have with gcc-3.4.3.20050110?

- im also interested in CFLAGS kimchi_sg posted for athlon xp, so my question to him is how stable/faster are they, and if it's worth changing (and I'm not planning on putting my system on the edge with ~x86 for packages)?

My system is stable and fast and I would like to keep it that way (this is the only OS i have at home, although I emulate windows with vmware).

thanks.

----------

## kimchi_sg

 *Zuti wrote:*   

> Now I read gcc-3.4.3.20050110 has some issues and that gcc-3.4.3-r1 should work better (faster?). I dont have any prob's and everything works great.
> 
> My questions are:
> 
> - what are the specific probs you have with gcc-3.4.3.20050110?

 

For the reasons why gcc-3.4.3-20050111 was and still is masked, check out the Changelog in your /usr/portage/sys-devel/gcc/ directory. Notably, it b0rks on -fstack-protector, iirc.

 *Zuti wrote:*   

> - im also interested in CFLAGS kimchi_sg posted for athlon xp, so my question to him is how stable/faster are they, and if it's worth changing (and I'm not planning on putting my system on the edge with ~x86 for packages)?
> 
> My system is stable and fast and I would like to keep it that way (this is the only OS i have at home, although I emulate windows with vmware).
> 
> thanks.

 

To keep things stable for as long as possible, i would advise you not to try my CFLAGS. And especially resist the temptation to re-install according to this tutorial.

All i can say about my CFLAGS is that they have not been the specific cause behind any of my emerge failures so far.

If your system is stable and zippy as it is now, great! No need to tweak anything if it is already in good working condition.  :Very Happy: 

You may even unmerge gcc-3.4.3 if you feel guilty about having tried anything ~x86.

----------

## Zuti

Thank you for the fast reply, i thought it wouldnt be a good idea(tm).

these are my flags now

```
CHOST="i686-pc-linux-gnu"

CFLAGS="-O3 -march=athlon-xp -mtune=athlon-xp -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe"

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

Dunno, maybe I'm lucky or something, but i dont have any probs with gcc-3.4.3.20050110.

Im not planning on going back to 3.3.5. Everything is stable and Im very much happy with it, only thing is: I didnt feel the speed improvment as much as I was hoping I would.

----------

## Lucifeer

Hmm seams that "emerge -e system" stopped during the night while compiling libstdc++ with gcc-3.4.3-rc1 also

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:39 am; edited 2 times in total

----------

## Bob P

 *nightmorph wrote:*   

>  *Bob P wrote:*    *mtamizi wrote:*   Bob P: Thanks for this tutorial.  It was very useful.
> 
> About the CFLAGS.  Most people are using those extra flags without realizing it, ie, some of the flags you listed are redundent.  According to GCC optimization website, -O3 already includes a lot of those options -- like -fomit-frame-pointer. 
> 
> indeed, you are right.  whenever you turn on any level of optimization using -Ox, -fomit-frame-pointer is enabled.  you will get -fomit-frame-pointer at -O1, for example.
> ...

 

Thanks for your feedback on the CFLAGS.  I seem to remember this conversation popping up already, but I don't remember if it came along in this thread (maybe it was Hobbitt?) or if it came up in one of the other threads.  You're definitely right, -fomit-frame-pointer doesn't come along automatically when optimizing on x86 as it does on other hardware.  In some respects, I think that this is moot, though, as the guide specifically mentions turning-on "-fomit-frame-pointer" when the "-O3" optimization level is used:

 *Stage 1/3 Guide wrote:*   

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

 

The need to set "-fomit-frame-pointer" independently of "-O3" on x86 platforms is displayed again in an example on this post  on page 7 of the thread.  Maybe I didn't make these points clear enough, so thanks for pointing out the architecture-specific idiosyncrasy for x86 and bringing up the fact that this may not be clear in the guide.  I'll put that on my list of things to update.   :Wink: 

 *nightmorph wrote:*   

> ...
> 
> Also, it's not a bad idea to explicitly declare the optimizations implied by -O3 as many ebuilds disable -O3 optimizations, switching to -O2 instead. This way certain functions (like -fweb and -frename-registers) are preserved even if some other processor-specific functions are removed. 

 

I've got a question for you about this -- if an e-build contains instructions to specifically disable -O3 optimizations, how effective will it be to manually/redundantly specify the CFLAGS that are contained in -O3?  For the approach of redundantly listing CFLAGS to be at all successful, it would seem that the ebuild's CFLAG-disabling method would have to be defective -- ie:  it would have to be ignorant of what CFLAGS are turned-on automatically with the -O3 level of optimization.  It would surprise me very much if every ebuild developer were careful enough to filter -O3, yet careless enough not to filter the actual flags specified by -O3.  Maybe I'm wrong and I'm just giving developers too much credit -- for being able to actually accomplish their programming goals.  :Confused: 

----------

## Bob P

 *Lucifeer wrote:*   

> the only problem I had was when re-emerging libdc++ during the "emerge -e system"-step, for some reason it refused to be compiled and gave me an error. Switching to gcc-3.3.4 for this package and abusing emerge --resume to switch to gcc-3.3.4 with gcc-config for this package was the workaround for me...
> 
> Wonder if that package will create future problems now =/ Oh well all I can do is wait

 

 *Lucifeer wrote:*   

> Hmm seams that "emerge -e system" stopped during the night while compiling libstdc++ with gcc-3.4.3-rc1 also

 

it appears evident that you've deviated from the guide by using toolkit packages older than those specified.  you've also compiled tooklit components with two different compilers  :Exclamation: 

you should reconsider this approach and pursue your support request in one of the support forums.

----------

## Lucifeer

older then those specified? Care to explain that abit more?

I followed the guide almost exactly, how can they be older then?

----------

## Bob P

 *Lucifeer wrote:*   

> older then those specified? Care to explain that abit more?

 

NO.  THIS IS NOT A SUPPORT FORUM.

 *Lucifeer wrote:*   

> I followed the guide almost exactly, how can they be older then?

 

unfortunately, "almost exactly" doesn't cut it.

it is beyond the scope of this guide to discuss the problems that you encounter when deviating from it.  if you have followed the Guide and you need support, you should post in the support forums, not here.  if you've encountered a problem with the Guide by deviating from it, you should post in the support forums, not here.

PS - removing any non-relevant material from the thread will help to keep it readable for people who are trying to follow the guide.

----------

## Lucifeer

You should stop with that attitude.

I never did ask for help, I just noted something that happened while following the guide.

And I doubt you know what I meant with "almost exactly" anyways, I followed the guide _except_ for your machine's hardware. AND later on tried to solve something else by changing compiler-version.

And I did ask you to simplify what you said as I didn't understand it, sorry for not being an american then

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:39 am; edited 5 times in total

----------

## Bob P

 *Lucifeer wrote:*   

> You should stop with that attitude.
> 
> I never did ask for help, I just noted something that happened while following the guide.
> 
> And I doubt you know what I meant with "almost exactly" anyways, I followed the guide _except_ for your machine's hardware. AND later on tried to solve something else by changing compiler-version.
> ...

 

American?  what does anyone's nationality have to do with anything?  

"older than those specified."  how much clearer could this possibly be?

Its evident that you did not follow the Guide -- you compiled toolkit components with a mixture of GCC 3.4.3 and GCC 3.3.4, even though the guide specifically requires that you compile your toolkit redundantly with GCC 3.4.3.  It should come as no surprise to anyone that problems would ensue when following such a deviant course.  When you don't follow the guide, I don't want to hear about your problems.

In regard to my attitude -- in order to be consistent and fair to everyone else who's been stomped-on for posting support requests in this thread, it is my duty to politely ask people who stray from the guide to take their support requests elsewhere.  When people refuse to pay attention to boldfaced red requests and persist under the assumption that the rules do not apply to them, the time for politeness has passed.  It was unfortunate that you choose to ignore the hints that had been provided for you.

----------

## Lucifeer

 *Bob P wrote:*   

> American?  what does anyone's nationality have to do with anything? 
> 
> "older than those specified."  how much clearer could this possibly be?

  Spoken and written language thats what, Im from none of the english-speaking contries. Your message made no sense so it might have been my lack of english knowledge that caused me to not understand it I thought.

 *Bob P wrote:*   

> Its evident that you did not follow the Guide -- you compiled toolkit components with a mixture of GCC 3.4.3 and GCC 3.3.4, even though the guide specifically requires that you compile your toolkit redundantly with GCC 3.4.3.  It should come as no surprise to anyone that problems would ensue when following such a deviant course.  When you don't follow the guide, I don't want to hear about your problems.

  Wtf? Quote from your guide:

 *Quote:*   

> 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.3. After making necessary updates to /etc/make.conf we need to rebuild the toolkit using the new GCC 3.4.3 compiler. The result will be a 3.4.3 tooklit, compiled by a 3.4.3 toolkit that was built with a 3.3.4 toolkit. Clear as mud? Rolling Eyes 

  YOUR _supposed_ to mix 3.3.4 and 3.4.3 acording to you how did I not follow the guide?

And second time I did follow your guide, but I began anew from scratch but using gcc-3.4.3-rc1 instead of the other unstable gcc-3.4.3

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:39 am; edited 1 time in total

----------

## Lucifeer

well thats what I did, except I had to switch to 3.3.4 for one package wich refused to compile with 3.4.3 for some reason

----------

## Bob P

 *nightmorph wrote:*   

> Here's the relevant information I learned from a very helpful software developer:
> 
>  *moocha wrote:*   -fweb -frename-registers are theoretically redundant (they're included in -O3) but the vast majority of ebuilds strip out -O3 replacing it with -O2, and this way the corresponding optimizations get kept. On a P3 arch they're perfectly safe, and are quite noticeable. 
> 
> It would indeed seem that many developers just strip out the -O3 optimization, but it is still possible to add in some of the theoretically "less stable" (though they really are perfectly safe) optimizations encountered at the -O3 level. Another idea is that when moving from -O2 to -O3, the packages built will definitely start to increase in size somewhat, and stripping out -O3 may be a somewhat misguided attempt to help keep down file sizes.

 

i'm still not sure that i understand what the ebuild developers are doing when the strip out the -O3 optimization.  are they just searching for the text "-O3" and replacing it with "-O2", or are they specifically looking for the individual flags that are implied in "-O3" and removing them as well?  as you can see, these two approaches will provide significantly different results at compile time if one specifies both "-O3" and the flags that are implied in "-O3".  in the first scenario, where the ebuild changes "-O3" to "-O2", you can bypass the stripping process by specifying the implied cflags.  in the second scenario, redundant specification of individual flags won't help.  whether or not our efforts to manually specifiy implied flags are successful depends entirely upon the individual ebuild's flag filtering algorithm.  personally, i find it beyond the scope of my willingness to inspect all of the individual ebuilds.  :Confused: 

----------

## Bob P

 *nightmorph wrote:*   

> Mmm, I meant to ask you--were it not for the fact that many users have had trouble with versions of gcc beyond 3.4.3-r1, would you otherwise wholeheartedly recommend it? I remember reading earlier in this thread about your experience with gcc 3.4.3.20050110, and it sounds like the dream compiler for this install method. Is the speed boost so noticeable even over more "stable" versions of gcc 3.4.x? 

 

i have experienced none of the problems that have been reported with any of the releases of gcc 3.4.3.  i have both gcc 3.4.3-r1 and 20050110 installed on my systems and i have never had problems with either one of them.  actually, i have never heard of an instance where a knowledgeable user has had problems with any of the gcc 3.4.3 ebuilds when following this guide.  so i am at a loss to explain why people are having problems with any of the 3.4.3 ebuilds.  

building the toolkit the way that i do, i have never encountered the problem.  in reading many of the threads that have discussed "issues" with gcc 3.4.3, i got the impression that the common denominator among people having problems was attributable to using update methods like "emerge -uD world" and not following the robmoss method of redundantly rebuilding the toolkit after a compiler upgrade.  (i could be wrong on that).  insofar as i have never observed these problems, i am of the impression that gcc 3.4.3 has been given a bad rap by users who have botched the upgrade and didnt' realize what they're doing wrong .  to discuss this, we should really be moving over to the GCC 3.4.3 threads.  my opinion is that it is safe to use gcc in the testing branch.

----------

## Lucifeer

 *nightmorph wrote:*   

>  *Lucifeer wrote:*   well thats what I did, except I had to switch to 3.3.4 for one package wich refused to compile with 3.4.3 for some reason 
> 
> That's a significant deviation from the published guide. Now that you know (for sure) that not once that Bob P required you to mix compilers, you've no excuse if something breaks. For that matter, this method is not guaranteed to work. In your case, you've proved that it doesn't work for you, or at least not with gcc 3.4.3. If you're still interested in it, try out one of the other gcc versions. Post about your experiences. But it's unreasonable to expect much help if you deviate from the guide in this way. If the issue was purely a gcc 3.4.3 problem, that might be relevant, in which case you might post a thread or bug report elsewhere.
> 
> And if your package still won't compile, look into a different version that does the same thing. Or examine your make.conf and post a support request on a different forum. Sorry, but if this method requires you to use an older gcc every time to make your system work, than this method isn't for you.
> ...

  Thats a better explanation. I just didn't understand it the way he put it wich is why I had to ask what he meant, instead of him getting angry for no reason at all.

So thank you

----------

## Bob P

 *nightmorph wrote:*   

> Oh, and I think revising an earlier part of your guide might be worth consideration in this regard. When it comes time to enable the use of a ~testing gcc, you rightfully point out that adding ~x86 to accept_keywords is unnecessary. You instead offer this solution, an update to package.keywords:
> 
> ```
> # cat /etc/portage/package.keywords
> 
> ...

 

well, yes.  if you read backward into the thread (page 4), i had thought about addressing the topic of package masking, but i had decided not to publish the tutorial i had written about it.  the Stage 1/3 Guide had already become a n00b magnet, and by writing it i had already fallen victim to continuous onslaught of requests for assistance from people who were so inexperienced that they really didn't understand the basis for rebuilding the toolkit and shouldn't have followed this advanced installation method.  it appeared that because so many people were having problems understanding the concepts in the guide, i thought it best to avoid opening the can of worms related to package masking and the maintenance of toolkit upgrades.  although i had already written a tutorial both in BBS code and as a PDF, i decided not to publish it, for fear of the support requests that would follow.

the subject of package masking and proper toolkit upgrades is something that i decided to leave out of the guide intentionally.  my idea on this was that people with the sophistication to master the subject could handle these issues on their own, and that people who couldn't handle package masking on their own shouldn't be spoon fed to the point that they are encouraged to follow a method that takes them in over their heads.

much to my delight, heilvc chose to address this topic by developing on his emerge wrapper for upgrading the toolkit.  that project is truly outstanding and i would recommend taking a look at it if you haven't done so already.  the project has taken on a life of its own, and compliments this guide very well.  in the big scheme of things, this guide is about installing gentoo, and heil's wrapper is about maintaining it.

 *nightmorph wrote:*   

> At first glance, though, by not specifying a particular version, it seems like that opens the door to unexpected and unwanted upgrades.

 

yes and no.   it all depends upon what the user decides to type at his keyboard.  IMHO, the commands like "emerge -uD system" and "emerge -uD world" amount to playing russian roulette.  only developers (who have to continually test everything) and n00bs (who are f00lish enough to upgrade everything) would consider using such an apporoach.  a rational approach to rebuilding/updating your system involves looking at the contents of the proposed emerge and making intelligent decisions.  portage is actually quite stupid in this regard, and doesn't do anything to help you.  heil's wrapper is deisgned assist in that regard, automating the process that an intelligent/experienced gentoo user would follow.

----------

## djpharoah

i cant wait for this setup to work..its being going on for the past 2 days on my P3M-700 in my ibm laptop..

wow..from what im hearring this setup is definitely the fastest...

good work bob

btw how do i get the html link in my signature pointing to this thread like everyone has?Last edited by djpharoah on Mon Feb 14, 2005 10:07 pm; edited 1 time in total

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:39 am; edited 2 times in total

----------

## Bob P

 *Lucifeer wrote:*   

>  Thats a better explanation. I just didn't understand it the way he put it wich is why I had to ask what he meant, instead of him getting angry for no reason at all.

 

this guide is written in english.  i have written it under the assumption that anyone who decides to use it has sufficient command of the english language to be able to use it effectively.  i don't think that such an assumption is too presumptive to make, but i guess i could be wrong on that.   :Embarassed: 

in your posts on this topic, you have not specified where you live, and the location field in your user profile is blank.  in addition, you have not bothered to tell anyone that you do not speak english as your first language.  it is impossible for anyone to know that a language barrier may exist if you do not tell anyone.

if a language barrier has caused a problem, i apologize for it.  i was assuming that because you had chosen to follow a guide written in english, that you knew enough english to follow it.  if you don't know enough english to follow it, maybe it would be helpful to either: 1) have someone else who understands english a bit better help you along, or 2) tell us about the lanugage barrier.

regardless of the "language barrier," it is evident that you read english well enough to have gotten through the entire installation guide and to be conversational in this forum.  this implies that you also understood the repeated warnings about posting support requests in this forum.  if you speak english well enough to get as far as you did in performing the installation, playing the language card won't cut it as an excuse for posting support requests here.  i got angry with you for the same reason that i get angry with everyone else who acts as if they are exempt from the rules that everyone else is good enough to follow.

i hate to have to play the role of the bad guy, but i have to do it to keep this thread under control.  if i weren't such a hardass about support requests, this thread would be two or three times as long as it is now, with no difference in the total amount of relevant content.  

when a user bloats this thread with an entire page of irrelevant material, i always ask that they remove their off-topic posts as a courtesty to the other users who are trying to follow the guide.  if you would be good enough to  delete your off-topic posts, nightmorph and i could follow in doing so.  this would make the thread easier to follow for everyone else.

----------

## Lucifeer

 *Bob P wrote:*   

> this guide is written in english.  i have written it under the assumption that anyone who decides to use it has sufficient command of the english language to be able to use it effectively.  i don't think that such an assumption is too presumptive to make, but i guess i could be wrong on that.  

  Bah please do give up, I understood the guide. I did not however understand the reason why you complained about what I wrote.

I did ask about the thing I did not understand but then you had to go into bastard-mode forcing me to defend myself instead

Instead of trying to act as an elitist bastard you could have avoided this by simply explaining what you meant in the first message or simply ignored complaining at all as you had no reason for it and I had no intention of writing anymore in this thread. I only wrote in the first place to make it as a comment about this guide and how it went for me. I thought that was the reason for this forum being open for discussion and not closed

----------

## Bob P

 *Lucifeer wrote:*   

>  *Bob P wrote:*   this guide is written in english.  i have written it under the assumption that anyone who decides to use it has sufficient command of the english language to be able to use it effectively.  i don't think that such an assumption is too presumptive to make, but i guess i could be wrong on that.    Bah please do give up, I understood the guide. I did not however understand the reason why you complained about what I wrote.
> 
> I did ask about the thing I did not understand but then you had to go into bastard-mode forcing me to defend myself instead
> 
> Instead of trying to act as an elitist bastard you could have avoided this by simply explaining what you meant in the first message or simply ignored complaining at all as you had no reason for it and I had no intention of writing anymore in this thread. I only wrote in the first place to make it as a comment about this guide and how it went for me. I thought that was the reason for this forum being open for discussion and not closed

 

if you do not appreciate my efforts in writing this guide, please send your flames to me via private messages.  they're not helpful to anyone else when you post them here.

----------

## thebigslide

I never use O3.  It is slower than O2 in terms of interactivity because it makes things too BIG.  O3 is only good on systems with TONS of RAM (1GB or more).

Recently, I have been using Os and enabling everything else manually and there are issues.  When I replaced the massive string of flags that should = O2, the problems go away.

This means a lot of developers are simple looking for Ox and replacing it.  if you want to build the system on edge, try individual package.cflags and enabling them individually.    This also gives you some extra granularity when troubleshooting a problem.  some cflags are commonly repeat offenders and should be avoided at all costs if you like your hair.  -ffast-math for example.

----------

## zbindere

GREAT!!!!

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:40 am; edited 1 time in total

----------

## kimchi_sg

 *nightmorph wrote:*   

> I have two questions for you, though, just to ease my peace of mind. First, in step 9.4.3, I'm supposed to download a .xpm image for grub. That's all well and good (I'm a big fan of grub/bootsplash), but once the file is downloaded, I'm at a loss as to what to do with it. The only time I've ever had to manually untar &/or move a file is during an initial install process; after that, I use the automation of Gnome's File-Roller. I don't know what directory (or what the commands are) to put it in so that I can use it.

 

Just make sure the file is in /boot/grub/ and then insert the "splashimage" line into grub.conf according to the example.

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:40 am; edited 1 time in total

----------

## kimchi_sg

 *nightmorph wrote:*   

> Ahhh, the light dawns. I just took another look at the directions: in step 9.4.1 i cd to /boot/grub, where I stay for quite awhile. I take it then that using wget automatically downloads the file to the directory I'm currently working in? And am I further right in assuming that grubsplash automatically takes care of the .gz at boot? And that I don't need to gunzip it or whatever; it only has to be in the /boot/grub directory.

 

Yes to all 3 questions.  :Smile: 

----------

## zbindere

Again I have to say this tutorial is great.

About the CFLAGS. I think they are OK. I only changed O3 to O2. Everything compiled flawlessly.

About performance: That stuff gives really an immense performance boost. Why buy new hardware  :Smile:  I am really thrillled. Because you can read in the forums

a lot about performance improvement. Only a few result in a performace boost that you can feel.

From my experience I can say the following things give a big performance improvement:

1. Your guide: CFLAGS and NPTL

2. Reiserfs (at least for the portage tree, rsync is at least 20-30% faster than with ext3)

Now I am looking for a good hdparm tuning guide. Disk is right now the only bottleneck I have.

----------

## Bob P

 *nightmorph wrote:*   

> First, in step 9.4.3, I'm supposed to download a .xpm image for grub. That's all well and good (I'm a big fan of grub/bootsplash), but once the file is downloaded, I'm at a loss as to what to do with it.

 

that file should get downloaded to /boot/grub/gentoo.xpm.gz.  once its there you don't have to do anything with it, other than to use the following line in your grub.conf file.  example from the guide:

```
# Use Gentoo Splash Image 

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

if you had decided not to update to our customized Grub Splash Image, you could use the default splash image that comes with Gentoo.  in that case, you's use the following line in grub.conf:

```
# Use default Grub Splash Image 

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

i thought that i had updated the guide to clarify this information -- it turns out that i actually did rewrite the grub.conf section in mid-January, but I didn't upload the PDF to the web.  :Embarassed:   thanks for pointing this out.  as soon as i have time i'll have to clarify this section of the guide and upload the revised PDF.

----------

## Bob P

 *nightmorph wrote:*   

> am I correct in assuming that I only throw in the rest of my USE list after I've rebooted into my new Gentoo environment? I think this would be the case, since otherwise anything other than the basic USE flags you've suggested would probably start pulling in package dependencies when I emerge programs.

 

no!  the answer to this question is so imporant that i'm going to colorize it so that it stands out in the thread.

it is imperative that you follow ALL of the steps in the guide and that you perform them in exactly the order given, without making any changes.  this means that you must update your make.conf entries before you rebuild the system toolkit, otherwise you won't gain any of the benefits that come from the new flags and your time spent recompiling will be wasted!

any updates that you make to make.conf will become active as soon as you issue the emerge command.  to demonstrate this, look at the output of "emerge info" before and after you edit the contents of make.conf.  the contents of make.conf get checked every time that emerge is executed, and there's no need to reboot in order to benefit from the updates.  stop thinking like a Windows user!  :Wink: 

in regard to pulling in other package dependencies -- if your new set of use flags require additional package dependencies, then you want those package dependencies to get pulled in after you rebuild your toolkit, and before you rebuild your system.   :Idea: 

i had anticipated that some people might lose sight of the forest for the trees by spreading out this information across sections 7.2.1, 7.2.2, 7.2.3, and 7.2.4, so i reviewed and summarized these steps in section 7.2.5 in attempt to make the BIG PICTURE more clear.

to gain a better insight of the big scheme of things, review section at 7.2.5.  it is absolutely critical that Steps 1, 2, and 3 be performed in the exact order shown, with no modifications.

----------

## 96140

 *Bob P wrote:*   

> it is imperative that you follow ALL of the steps in the guide and that you perform them in exactly the order given, without making any changes.  this means that you must update your make.conf entries[/color] before you rebuild the system toolkit, otherwise you won't gain any of the benefits that come from the new flags and your time spent recompiling will be wasted!

 

Uh oh. Right now I'm in the middle of the first "emerge -e system", but I've only used the basic USE flags that you provided in the beginning of the HOWTO. I noticed earlier that the first time I tried this method, I had some problems with the USE flags I had intended to use. While they've been fine for my previous system (wtih nptl and nptl only), they seemed to cause some problems. I'm talking about USE flags here, not the CFLAGS; I've fixed the problem there as I mentioned in an earlier post. I thought I only had to add in the rest of the USE flags (not just the minimal set presented at the start of this guide for initial installation) AFTER doing "emerge -e system". So I think I'm going to halt the emerge -e system right now, go back, add in the new USE flags, then do "emerge --newuse glibc binutils gcc portage" for step 7.2.4. Maybe it's not the right thing to do, but that's what experimentation is for, and it might save me a lot of compile time later. Maybe I'll keep in the --newuse flag for both toolchain rebuilding and emerge -e system.

(by the way, just an aside: I've noticed that when compiling gcc 3.4.3.x with a 3.4.3.x compiler, as well as my other toolchain bits, -O3 pretty much gets stripped out. Most annoying; the damn ebuild uses -O2 just about without fail, so I know that I've lost some of the optimizations I wanted.)

----------

## DrWoland

 *nightmorph wrote:*   

>  *Bob P wrote:*   it is imperative that you follow ALL of the steps in the guide and that you perform them in exactly the order given, without making any changes.  this means that you must update your make.conf entries[/color] before you rebuild the system toolkit, otherwise you won't gain any of the benefits that come from the new flags and your time spent recompiling will be wasted! 
> 
> Uh oh. Right now I'm in the middle of the first "emerge -e system", but I've only used the basic USE flags that you provided in the beginning of the HOWTO. I noticed earlier that the first time I tried this method, I had some problems with the USE flags I had intended to use. While they've been fine for my previous system (wtih nptl and nptl only), they seemed to cause some problems. I'm talking about USE flags here, not the CFLAGS; I've fixed the problem there as I mentioned in an earlier post. I thought I only had to add in the rest of the USE flags (not just the minimal set presented at the start of this guide for initial installation) AFTER doing "emerge -e system". So I think I'm going to halt the emerge -e system right now, go back, add in the new USE flags, then do "emerge --newuse glibc binutils gcc portage" for step 7.2.4. Maybe it's not the right thing to do, but that's what experimentation is for, and it might save me a lot of compile time later. Maybe I'll keep in the --newuse flag for both toolchain rebuilding and emerge -e system.
> 
> (by the way, just an aside: I've noticed that when compiling gcc 3.4.3.x with a 3.4.3.x compiler, as well as my other toolchain bits, -O3 pretty much gets stripped out. Most annoying; the damn ebuild uses -O2 just about without fail, so I know that I've lost some of the optimizations I wanted.)

 

Actually, that's GCC devs saving you some headaches. GCC itself probably wouldn't compile with all those flags. It's better to have a stable, robust compile of that.

----------

## Bob P

USE FLAGS?

the Guide mentions the initial modification of USE flags in section 6.5.  beyond that, the Guide remains mute on the subject of USE flags on purpose.  if the user has specific applications that require the modification of the sample USE flags, he's expected to be capable of making those changes on his own, insofar as it is impossible for the Guide to predict what USE flags would be appropriate for a customized Gentoo installation.

even if USE flags weren't mentioned in section 6.5, it would make sense to change the USE flags sooner, rather than later, and definitely before recompiling the entire system, not after you finish the installation.  that is, unless you just like to watch your machine compile...

regarding your idea of stopping emerge -e system and restarting the emerge with the --newuse parameter, you really need to reivew the man page for emerge if you're seriously considering doing something like that.  you might also want to post any additional support questions in the support forums.

----------

## 96140

 *DrWoland wrote:*   

> Actually, that's GCC devs saving you some headaches. GCC itself probably wouldn't compile with all those flags. It's better to have a stable, robust compile of that.

 

Actually, as I've referenced earlier in this thread, it's not a bad idea to add back in some of the optimizations that are inherent to specifying "-O3", or at least the ones that the user KNOWS are perfectly safe (in theory, everything that's part of -O3, but YMMV). I thought about including EVERY optimization specified by -O3, but that would have been time-consuming. I was right; it looks like developers only look for the -O3 flag, not the individual flags that are part of it. So I am still getting some of the benefits of my preferred optimization level. As Bob P and others have pointed out, Pentium IIIs seem to be immune to a lot of architecture-specific bugs that are part of other processors. I just wish that -O3 wasn't removed. It seems like a waste of a good thing.

Here we have this excellent tune-up install method by Bob, and then the very toolchain we are trying to build can't be optimized as much as it needs to be. All I see in almost every compile output line is a substitution of -O2 for -O3. Maybe I could have just used "nptl nptlonly" USE flags the way I did in my first Gentoo system, but I'm not willing to break the "bulletproof" method offered here, despite the definite speed boost I would obtain. I'm not all that cagey, but I recognize that there needs to be a certain level of safety. I just wish the gcc developers wouldn't remove all possibilities from the start; that makes me have less confidence in their abilities as programmers. Reading the GNU gcc online manual seems to indicate that the optimizations gained from judicious CFLAGS use are perfectly safe. But, I don't want this to degenerate into a discussion of CFLAGS; there are plenty of other threads on that. I do still maintain that it's not a bad idea to specifiy redundant CFLAGS for this install method, in step 7.2.1. Hasn't hurt so far, and if you read Bob P's thread In Praise of gcc 3.4.3.20050110, it would seem that this method can indeed be completed with the use of -O3 CFLAGS, and with great results. On a Pentium III, that is.

----------

## Bob P

 *nightmorph wrote:*   

> Actually, as I've referenced earlier in this thread, it's not a bad idea to add back in some of the optimizations that are inherent to specifying "-O3", or at least the ones that the user KNOWS are perfectly safe (in theory, everything that's part of -O3, but YMMV). I thought about including EVERY optimization specified by -O3, but that would have been time-consuming. I was right; it looks like developers only look for the -O3 flag, not the individual flags that are part of it.

 

aargh.  it would be a real PITA to sift through the gcc man pages, but if the devs are going to insist on deciding what's good for us by replacing -O3 with -O2, we may have no choice other than to do exactly that.   :Mad: 

personally, i find it unconscionable that gentoo developers would usurp the end user's decision on how to optimize their system because the devs are trying to hide from bug reports.  ciaranm is pretty outspoken on this.   :Rolling Eyes: 

 *Quote:*   

> I just wish that -O3 wasn't removed. It seems like a waste of a good thing.
> 
> Here we have this excellent tune-up install method by Bob, and then the very toolchain we are trying to build can't be optimized as much as it needs to be
> 
> 

 

you know, i have always been to lazy to edit ebuilds, based on the principle that it isn't worth my time.  but if we're going to have people like ciaranm acting like Big Brother and deciding what's good for us, i may change my mind on that.  maybe the toolkit edbuilds would be worthy of an edit.   :Idea:   this, of course, would only result in an underground version of Gentoo for ricers.  

 *Quote:*   

> All I see in almost every compile output line is a substitution of -O2 for -O3.

 

i have to admit, i haven't downloaded a recent toolkit in at least a month.  i'm still using 3.4.3-r1 and 3.4.3.20050110 -- the original versions that came along before all of the hardmasking/unmasking took place -- and i am not seeing -O3 dumbed down to -O2 on my screen output.  i am watching kde compile right now, and i see -O3 in the screen output.  about a month ago ciaranm was quite vocal about filtering in ebuilds to force them to not perform -O3 optimizations.  i wonder if they've started to dumb down all of the ebuilds.  if that's the case, then Gentoo only provides us the the illusion of choice -- while limiting the user to the choices that Big Brother deems safe for us to make.  :Twisted Evil: 

----------

## thebigslide

 *DrWoland wrote:*   

>  *nightmorph wrote:*    *Bob P wrote:*   it is imperative that you follow ALL of the steps in the guide and that you perform them in exactly the order given, without making any changes.  this means that you must update your make.conf entries[/color] before you rebuild the system toolkit, otherwise you won't gain any of the benefits that come from the new flags and your time spent recompiling will be wasted! 
> 
> Uh oh. Right now I'm in the middle of the first "emerge -e system", but I've only used the basic USE flags that you provided in the beginning of the HOWTO. I noticed earlier that the first time I tried this method, I had some problems with the USE flags I had intended to use. While they've been fine for my previous system (wtih nptl and nptl only), they seemed to cause some problems. I'm talking about USE flags here, not the CFLAGS; I've fixed the problem there as I mentioned in an earlier post. I thought I only had to add in the rest of the USE flags (not just the minimal set presented at the start of this guide for initial installation) AFTER doing "emerge -e system". So I think I'm going to halt the emerge -e system right now, go back, add in the new USE flags, then do "emerge --newuse glibc binutils gcc portage" for step 7.2.4. Maybe it's not the right thing to do, but that's what experimentation is for, and it might save me a lot of compile time later. Maybe I'll keep in the --newuse flag for both toolchain rebuilding and emerge -e system.
> 
> (by the way, just an aside: I've noticed that when compiling gcc 3.4.3.x with a 3.4.3.x compiler, as well as my other toolchain bits, -O3 pretty much gets stripped out. Most annoying; the damn ebuild uses -O2 just about without fail, so I know that I've lost some of the optimizations I wanted.) 
> ...

 

man gcc and put the equivilent flags in make.conf and then it won't get filtered  :Smile: .  It'll probably break, tho

----------

## DrWoland

 *Bob P wrote:*   

>  *nightmorph wrote:*   Actually, as I've referenced earlier in this thread, it's not a bad idea to add back in some of the optimizations that are inherent to specifying "-O3", or at least the ones that the user KNOWS are perfectly safe (in theory, everything that's part of -O3, but YMMV). I thought about including EVERY optimization specified by -O3, but that would have been time-consuming. I was right; it looks like developers only look for the -O3 flag, not the individual flags that are part of it. 
> 
> aargh.  it would be a real PITA to sift through the gcc man pages, but if the devs are going to insist on deciding what's good for us by replacing -O3 with -O2, we may have no choice other than to do exactly that.  
> 
> personally, i find it unconscionable that gentoo developers would usurp the end user's decision on how to optimize their system because the devs are trying to hide from bug reports.  ciaranm is pretty outspoken on this.  
> ...

 

I think he was talking about emerging gcc itself. I haven't seen any flag substitution in anything but toolkit compiles.

----------

## thebigslide

One can always just add

CFLAGS+=" -fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-follow-jumps  -fcse-skip-blocks -frerun-cse-after-loop  -frerun-loop-opt -fgcse  -fgcse-lm -fgcse-sm  -fgcse-las -fdelete-null-pointer-checks -fexpensive-optimizations -fregmove -fschedule-insns  -fschedule-insns2 -fsched-interblock  -fsched-spec -fcaller-saves -fpeephole2 -freorder-blocks  -freorder-functions -fstrict-aliasing -funit-at-a-time -falign-functions  -falign-jumps -falign-loops -falign-labels -fcrossjumping -finline-functions, -fweb and -frename-registers"

to make.conf...

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:44 am; edited 1 time in total

----------

## Bob P

this is the point where i play the broken record that keeps on saying: 

 *Quote:*   

> it is unfair to everyone who is reading this thread to waste space talking about problems that have cropped-up as a result of deviating from the recommended installation method. if you have deviated from the guide in any way and you have encountered a problem, then please do not post about your problems in this thread. give your problem its own thread in the support forums and take your troubleshooting coversation there.  it just isn't fair to bloat this thread with material that is 100% relevant to you, and 100% irrelevant to everyone else.  that's what the support forums are for.

 

----------

## Bob P

 *thebigslide wrote:*   

> I never use O3.  It is slower than O2 in terms of interactivity because it makes things too BIG.  O3 is only good on systems with TONS of RAM (1GB or more).

 

after benchmarking a collection of obsolete PCs with acovea, i agree with robmoss that outperformance by -Os on older processors is nothing more than a myth.

my experience has been that -O3 outperforms -Os even on lowly pentium systems with the recommended minimum amount of memory.  the only time that this isn't the case is when you're dealing with extremely small embedded systems.  but we're going off on a tangent again.  this subject has already been beaten to death in Portage & Programming.

----------

## COiN3D

Question, lead this guide to a complete system rebuild? You said if I have an other arch than x86 I should choose that. That's ok, but I wanted to try out an experimental 2005.0 Stage-3 x86 Tarball. But I have an athlon xp, so will everything be rebuilt?

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:43 am; edited 2 times in total

----------

## Bob P

 :Exclamation:  GUIDE UPDATED TODAY.  :Exclamation: 

- PDF sync'd with Installation Guide

- Revised Section 9.4 to clarify the installation of the Gentoo grub splash screen

- Revised Section 9.7 to add example of "wheel" group user 

- Plugged the hielvc/MindEraser emerge wrapper

----------

## po0f

Just wanted to say thank you Bob P for a wonderful guide.  Took me ~3 days, but I got it up and running.  Still having some issues, but those are being slowly ironed out.  Keep up the good work.

----------

## bkunlimited

bob, thanks for that guide!! got it running easily w/o any problems!!! (even with heavy optimization flags)

----------

## Nemein

I should truly thank Bob for taking the time to make this tutorial and letting me in on the Gentoo world. It took me roughly 6 days of trial and error but thank you nonetheless Bob  :Smile: 

----------

## Bob P

 :Exclamation:  PLEASE NOTE:  A new thread has been opened in the Installing Gentoo forum for the purpose of handling support requests for this installation method.  The thread may be found here:

Stage 1 on a 2004.3 Stage 3 Tarball Support Thread.

PLEASE POST ALL SUPPORT REQUESTS TO THE SUPPORT THREAD.  

No support questions should be posted here.  

In addition, I will no longer respond to any Personal Messages asking for support.

Good luck with your installation, and Have Fun with your new Gentoo box!   :Very Happy: 

----------

## R!tman

Thanks, this is a very nice howto.

----------

## Cpoc

Thank you Bob for your install method. I have already done 2 installs and it was flawless as long as you do eveything in the guide. 

The only think I did not was I used standard safe CFAGS instead of the heavy optimized ones.

I beleieve that your method should be the standard method of installing Gentoo. Gentoo takes allot longer to install than other distros but you will have a very fast and optimized system to suite your exact needs.

----------

## MishY

Installed this today - thanks for the guide

----------

## Master One

Thank's a lot, Bob P. This installation method is absolutely revolutionary, and as long as there is no "Gentoo-out-of-the-box" way to get the toolkit in this order on a new installation, I'd never use another installation method / stage1 installation again.

I performed my first "Stage1 on a Stage3 tarball" installation on my new IBM ThinkPad T42p, using Reiser4 as filesystem, and the full set of stacked-cflags + ldflags mentioned in this thread, and everthing worked out without a single problem. At first I was not sure if everything would compile with such an extreme level of code optimization, but I really can confirm, that this is the most stable system I ever set up until now:

```
# (choose optimization level)

CFLAGS="${CFLAGS} -O3"

#CFLAGS="${CFLAGS} -O2"

# (use these only if -O2, they are included in -O3)

CFLAGS="${CFLAGS} -fweb"

CFLAGS="${CFLAGS} -frename-registers"

# (choose additional flags as appropriate)

CFLAGS="${CFLAGS} -march=pentium-m -pipe"

CFLAGS="${CFLAGS} -mtune=pentium-m"

CFLAGS="${CFLAGS} -fforce-addr"

CFLAGS="${CFLAGS} -momit-leaf-frame-pointer"

CFLAGS="${CFLAGS} -fomit-frame-pointer"

CFLAGS="${CFLAGS} -ftracer"

# (optional CFLAGS suggested by kimchi_sg)

CFLAGS="${CFLAGS} -funroll-loops"

CFLAGS="${CFLAGS} -falign-functions"

CFLAGS="${CFLAGS} -fmerge-all-constants"

CFLAGS="${CFLAGS} -mfpmath=sse"

CFLAGS="${CFLAGS} -maccumulate-outgoing-args"

CFLAGS="${CFLAGS} -fprefetch-loop-arrays"

# (CXXFLAGS: choose one)

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

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

#CXXFLAGS="${CFLAGS}"

LDFLAGS="-Wl,-O1"
```

I use the additional O2 flags by standard, also I am on O3, since I remember to have read about ebuilds, stripping the O3 flag, so this only adds some redundancy as long as it stays on O3, but adds the extra benefit, if O3 should get replaced with O2 by an ebuild.

Concerning "-fvisibility=hidden": I have read, that KDE packages (up to KDE 3.3.2) can make troubles with this cxxflag, but as I have seen, this should not be the case for KDE 3.4, that's why I'm gonna try KDE 3.4 beta2 now with my set up flags.

----------

## Bob P

 *Master One wrote:*   

> Thank's a lot, Bob P. This installation method is absolutely revolutionary, and as long as there is no "Gentoo-out-of-the-box" way to get the toolkit in this order on a new installation, I'd never use another installation method / stage1 installation again.
> 
> I performed my first "Stage1 on a Stage3 tarball" installation on my new IBM ThinkPad T42p, using Reiser4 as filesystem, and the full set of stacked-cflags + ldflags mentioned in this thread, and everthing worked out without a single problem. At first I was not sure if everything would compile with such an extreme level of code optimization, but I really can confirm, that this is the most stable system I ever set up until now:[code]# (choose optimization level)
> 
> ...
> ...

 

thanks for your kind words.  as i was reading your post i noticed that you had uncommented the -fweb and -frename-registers cflags, presumably because you knew about cflag stripping in ebuilds.  i've looked into that and confirmed that there are quite a few ebuilds that strip cflags, and quite a few that replace cflags, so unmasking those two flags, is a good idea, even though it may seem redundant.

if anyone is wondering about how severe the cflag filtering problem turns out to be, here is a grep command that you can use to search the portage tree/ebuilds for flag stripping and/or replacement:

[code]

mkdir ~/tmp

find /usr/portage/ -name *ebuild | xargs -- grep 'O3' {} \; |sort |uniq >~/tmp/strippedflags

[/code]

if you look at the output, you'll see that the vast majority of ebuild developers take the easy way out and replace -O3 with -O2.  very few of them actually strip out the individual cflags that are components of -O3 optimization, so its a good idea to uncomment -fweb and -frename-registers.  if the ebuild doesn't replace -O3 with -O2, the flags will just be set redundantly, and if it does replace -O3 with -O2, you can restore some degree of optimization that would otherwise be lost.

 *Master One wrote:*   

> Concerning "-fvisibility=hidden": I have read, that KDE packages (up to KDE 3.3.2) can make troubles with this cxxflag, but as I have seen, this should not be the case for KDE 3.4, that's why I'm gonna try KDE 3.4 beta2 now with my set up flags.

 

i can verify that many of the KDE 3.3.2 ebuilds will b0rk if the -fvisibility=hidden flag is set.  k3b is another prime offender.  its a pain in the ass to emerge those packages, as you always have to use package-specific CFLAG settings for them, and then set your CFLAGS back to your default settings when you're done. 

i had not heard that the flag problem would be fixed in KDE 3.4.  if that is indeed the case, then that is very good news, and KDE 3.4 is something that i will be looking forward to.  if you try the beta package, please report back to us and let us know whether your tests were successful.

thanks!  :Wink: 

----------

## Master One

 *Bob P wrote:*   

> i can verify that many of the KDE 3.3.2 ebuilds will b0rk if the -fvisibility=hidden flag is set.  k3b is another prime offender.  its a pain in the ass to emerge those packages, as you always have to use package-specific CFLAG settings for them, and then set your CFLAGS back to your default settings when you're done. i had not heard that the flag problem would be fixed in KDE 3.4.  if that is indeed the case, then that is very good news, and KDE 3.4 is something that i will be looking forward to.  if you try the beta package, please report back to us and let us know whether your tests were successful.

 

As expected, the emerge of kdebase-meta (3.4 beta2) worked flawlessly with "-fvisibility=hidden", so I could keep my whole set of flags  :Very Happy: 

The only things to take care:

- latest "x86" version of aspell didn't like "-fvisibility=hidden", but latest "~x86" version (0.60.2) did

- fam didn't want to compile with "-fvisibility=hidden", had to "oneshot" it without that flag before starting the kdebase-meta emerge

This is very exciting, KDE3.4.0_rc1 has just been released today. The ebuilds for arts and kdelibs are already in portage, and I just upgraded these two packages. I do not expect any of the KDE 3.4 programs to cause any troubles with "-fvisibility=hidden".

----------

## Master One

BTW I wanted to mention, that I use the following method in /etc/portage/package.keywords for nearly all "~x86" packages, which I emerge on my "x86" system:

```
# Toolkit

=sys-devel/gcc-3.4.3.20050110

=sys-devel/gcc-config-1.3.10-r1

=sys-libs/glibc-2.3.4.20050125

=sys-libs/libstdc++-v3-3.3.4
```

This way, I fetch the latest "~x86" version at the time I play arround with it, and then I don't have to care any more about those packages, until the next stable "x86" version becomes available (there should be no need, to perform the usually frequent updates in the "~x86" branch, as long as you don't experience any problems with the installed version). This makes it much easier, to concentrate on more important things.  :Wink: 

----------

## thebigslide

 *Bob P wrote:*   

> 
> 
> i can verify that many of the KDE 3.3.2 ebuilds will b0rk if the -fvisibility=hidden flag is set.  k3b is another prime offender.  its a pain in the ass to emerge those packages, as you always have to use package-specific CFLAG settings for them, and then set your CFLAGS back to your default settings when you're done. 
> 
> i had not heard that the flag problem would be fixed in KDE 3.4.  if that is indeed the case, then that is very good news, and KDE 3.4 is something that i will be looking forward to.  if you try the beta package, please report back to us and let us know whether your tests were successful.
> ...

 

It is easy to use a file like /etc/portage/package.cxxflags to override cxxflags for specific offenders.

I also wanted to bring up a point that someone made on a previous page where it was stated that if both march and mtune were used in c/cxxflags that the last one asserted would be taken by the compiler.  This information is INCORRECT and it is clearly stated in the gcc man page.  One can optimize code like -march=pentium3 -mtune=athlon-xp to force sse and allow 3dnow if available, for example.

----------

## kailauro

There are many questions that arises when puzzling through the labyrinth to build an optimized system. One question covers them but it might have been asked a million times (didn't spot this in this thread)

Doesn't hard optimization of the toolchain restrict the toolchain from building an optimized rest_of_the system or are we having a petbief for just making the toolchain faster ??

If building the toolchaing takes a nice heaps of hours what does it matter if a TRULY optimized system takes just that little longer to build if it really is done with less restricted toolchain??

Or is it that toolchain-optimization won't affect the output of the toolchain at all?

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

Maybe a silly question is allowed for a newbie.

PS. Following this quide to the detail

----------

## kimchi_sg

 *kailauro wrote:*   

> There are many questions that arises when puzzling through the labyrinth to build an optimized system. One question covers them but it might have been asked a million times (didn't spot this in this thread)
> 
> Doesn't hard optimization of the toolchain restrict the toolchain from building an optimized rest_of_the system or are we having a petbief for just making the toolchain faster ??
> 
> If building the toolchaing takes a nice heaps of hours what does it matter if a TRULY optimized system takes just that little longer to build if it really is done with less restricted toolchain??
> ...

 

 :Question:  Your english is truly easy to understand.

That said, optimising the toolchain will make it faster. It will have no ill effect at all on the generated code.

----------

## kailauro

Vielen danke for a reply.

I thereby take it as a fact that the binaries will be made according to appropriate flags regardles of how the toolchain was optimized.

Compiling is going to be just that much more fun.

---the nyyb

----------

## kailauro

quote " ... will equal or exceed that of any other Gentoo installation method..."

saved me an awful lot of time dealing with bootstrapping troubles...adding USE-flags one by one when dealing with dependencies, resulted in a unified , indeed nice and working result without one single unexpected error or misbehaviour whatsoever. Just what was wanted from linux at the moment.

Thanks for a great procedure that tributes the gentoo way

This I will back up now and maybe concider getting back to this business in 6 months from now...

...the happy pumpkin arctic neubie

----------

## Master One

 *thebigslide wrote:*   

> It is easy to use a file like /etc/portage/package.cxxflags to override cxxflags for specific offenders.

 

Can someone explain, how entries in package.cxxflags should look like, please?

I could not find any info about this file in man portage, and I never heard of this possibility before.

I am still emerging kde-3.4.0_rc1, so far everything works fine, only kpovmodeler didn't like "-fvisibility=hidden".

----------

## kimchi_sg

 *Master One wrote:*   

>  *thebigslide wrote:*   It is easy to use a file like /etc/portage/package.cxxflags to override cxxflags for specific offenders. 
> 
> Can someone explain, how entries in package.cxxflags should look like, please?
> 
> I could not find any info about this file in man portage, and I never heard of this possibility before.

 

You need thebigslide's brilliant script for this to work: https://forums.gentoo.org/viewtopic-t-280748-start-0-postdays-0-postorder-asc-highlight-perpackage+cflags.html

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:43 am; edited 1 time in total

----------

## Arainach

 *kailauro wrote:*   

> Vielen danke for a reply.
> 
> I thereby take it as a fact that the binaries will be made according to appropriate flags regardles of how the toolchain was optimized.
> 
> Compiling is going to be just that much more fun.
> ...

 Correct.  The output is the same; optimizing the toolchain simply makes it work MUCH faster, thus saving compile time.

----------

## kimchi_sg

How about emerging ccache early on in the installation process?

Ccache is not enabled until you explicitly emerge it, on top of having "ccache" in FEATURES.  :Surprised: 

----------

## Crete

I am not ready for this but I hope to be someday:wink:.  Good to know I have alot of room to grow though..heh.

----------

## kailauro

I DO believe what you say about those binaries being compiled regardles of the toolchain being optimized. This procedure is being applied here with indeed nice results.

I'd stil like to know whats the difference between ...lets say KDE that was build using gcc plus the libraries that were build using :	

CFLAGS="-O3 -march=pentium -mtune=pentium -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe" 

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

and kde that was build using exactly the same flags exept with a compiler that whas build using no O -flags or other optimization at all.

I'd like to know what's the reason for both kde's being exactly the same. and especially...if the kde being build is optimized in both cases....would the compilers STILL give the exact same results.

I'd like to test but I'm sure there are good knowledge about this that I lack. and that someone could also interpret the result.

For a newbie it is kind of hard to believe that a compiler that "omits, forces, hides" and does skip parts in the process...still outputs the same OPTIMIZED binaries.

----------

## slycordinator

 *kailauro wrote:*   

> For a newbie it is kind of hard to believe that a compiler that "omits, forces, hides" and does skip parts in the process...still outputs the same OPTIMIZED binaries.

 

Optimizing gcc (the compiler itself) will change HOW WELL it performs but not WHAT it performs.  

So if gcc isn't optimized at all and you use it to compile a program using optimized cflags what happens is this:

gcc creates the optimized binaries but takes longer than optimal to do it.

----------

## kimchi_sg

 *slycordinator wrote:*   

> So if gcc isn't optimized at all and you use it to compile a program using optimized cflags what happens is this:
> 
> gcc creates the optimized binaries but takes longer than optimal to do it.

 

The fun part about using less optimisation is this: You will get to spend more time away from the computer, wondering when on Earth it will ever, ever finish compiling KDE.  :Laughing: 

----------

## kailauro

there was a little linguistic typo earlier...ofcourse the compiler is not compiled to "omit and hide" but aren't those features that are being omitted and hidden NEEDED to build a compiler that is capable of optimizing the binaries to perform faster when run.

so a program is coded to do WHAT it does.  and it's optimized with compiler flags to effect HOW it does what it does.

Am I given a better shovel to dig faster with optimization flags? (by for example using features on the CPU)

                   OR

Am I being taken away the tools to tune up a racing vehicle to run fast ??

----------

## kailauro

here's my question in detail....

if I build the very compiler and libs to:

          -fforce-mem

          -foptimize-sibling-calls

          -fstrength-reduce

          -fcse-follow-jumps  -fcse-skip-blocks

          -frerun-cse-after-loop  -frerun-loop-opt

          -fgcse   -fgcse-lm   -fgcse-sm

          -fdelete-null-pointer-checks

          -fexpensive-optimizations

          -fregmove

          -fschedule-insns  -fschedule-insns2

          -fsched-interblock -fsched-spec

          -fcaller-saves

          -fpeephole2

          -freorder-blocks  -freorder-functions

          -fstrict-aliasing

          -falign-functions  -falign-jumps

          -falign-loops  -falign-labels

(the -O2 flag alone does this let alone O3 +)

Does the compiler still have the functionality to make faster binaries?

----------

## kimchi_sg

 *kailauro wrote:*   

> Am I given a better shovel to dig faster with optimization flags? (by for example using features on the CPU)

 

Yes.

The follwing point is very important so I will put it in bold, blue and large font:

Using optimisations does not change, reduce or add to the abilities of either the toolchain doing the compiling, or the toolchain being re-compiled. Your newly compiled toochain will have all the functionality of the old, pre-compiled one, only it can do things faster.

(Apologies to Bob P for ripping off his "emergency" reply style.  :Razz:  )

I will not reply to your second post, because I think by asking so many questions, you are rapidly confusing yourself, and the second post is a good example of your confusion. Please, wait for other people to answer your questions, before you get all worked up wondering if the toolchain will have reduced power if it gets re-compiled.  :Laughing: 

Also, I think you have not bothered to read our replies, otherwise Slycoordinator's reply to your first post in this topic would have cleared up the issue for you already. I prefer to think of more meaningful ones, like whether my legs will get tired after running 6km, or whether your forums signature has any meaning at all.  :Wink: 

----------

## Sheepdogj15

well, i'm happy to report that i had a virtually problemless Stage 1 install on Stage 3 tarball on the AMD64 archtecture. 

i only had one problem and that was with the Gensplash thing, but it isn't important enough to me to spend time troubleshooting so i'll live contently with a nice system lacking bootsplash. everything else worked fine.

there are a few deviations from the instructions to note for amd64. For one, gcc 3.4.3 is marked as stable for amd64 (but not in x86... figure that one out  :Laughing: ).  also, the 2004.3 live CD came with 3.4.2, which was also stable for amd64. but despite that i still did the emerge to gcc 3.4.3, assuming that there might be some optimization (even if not as great as from 3.3.4). 

when gcc was said and done, 3.4.3 was already set to default, which was strange, but oh well.

also, it should be noted that if someone does this, they should read the supplimental info on amd64 first. for instance, if you want 32bit compatibility (needed if you want nice proprietary crap like flash or real/win codecs), you must have multilib in your USE flags prior to emerging GCC. also make sure you have IA32 Emulation turned on in the kernel, and eventually you might want to emerge these:

emerge app-emulation/emul-linux-x86-baselibs

emerge app-emulation/emul-linux-x86-xlibs

emerge app-emulation/emul-linux-x86-gtklibs

emerge app-emulation/emul-linux-x86-qtlibs

last i checked the qtlibs one was masked. i haven't needed it yet but if need just use ACCEPT_KEYWORDS="~amd64"; but for criminy sakes don't put that in your make.conf.

other than that, there isn't much difference. substitute "amd64" everywhere where the tutorial calls for "x86". 

my cflags stuff:

CHOST="x86_64-pc-linux-gnu"

CFLAGS="-march=athlon-64 -O2 -pipe -fweb -frename-registers"

CXXFLAGS="${CFLAGS}"

as you can see they almost as conservative as Rush Limbaugh. but that isn't a bad thing as i've had woolier cflags break GCC in the past.

----------

## kailauro

Thanks kimchi_sg & slycordinator for your answers.

I had trouble making a point about something that I have a very simple abstraction about and not that much knowledge. No confusion here.

Not that many people seem  know what really happens after the source has been sent to compilation. also the toolchain is used to compile the system that includes all kinds of functionality that a computer can possibly have!! 

Given the nature of that low-level processing that takes place it's not in my knowlege at all how the binaries are  given a faster performing form.

I knew that I'm douting somethign that questions believes about what we're doing and putting lot's of effort to.

So my really and truly last question would be....

Do that answer of yes and no base on a causal knowledge about the inner workings of gcc or is it a belive that has some trial and error evidence to ackowledge??

Should I try to get in touch with makers of gcc. There wasn't that many references to those folks @ gcc home  :Wink: 

feel free to erase, simplify or edit my questioning. 

I'm so very pleased that this procedure really does have a nice result. No problems whatsoever. Just a great improvement in smoothnes of using computer between a gentoo prepared this way and any other distro I've tried. Giving the computer some extra lifespan.

I'll be doing this on another box as well. Why in the heck not!!

I'll go on with the "press this to get this" -philosopfy for now on this matter...

PS. could you also make bzip2 perform at the speed of tar?

Yours, Kai Lauronen

----------

## ronvenema

RemovedLast edited by ronvenema on Sat Mar 05, 2005 3:08 pm; edited 1 time in total

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:51 am; edited 1 time in total

----------

## Heidrun

Just a detail in the guide at the first page section 9.4.1Grub.conf...

 *Quote:*   

> # By default, boot the first entry.
> 
> default 1
> 
> # Fallback to the second entry.
> ...

 

shouldn't it be:

```
# By default, boot the second entry.

default 1

# Fallback to the first entry.

fallback 0
```

P.s. Nice guide! will try using it on my AMD64.

----------

## Bob P

 *thebigslide wrote:*   

> It is easy to use a file like /etc/portage/package.cxxflags to override cxxflags for specific offenders.

 

you know, someday when i have a little spare time i am going to get around to learning how to do your package-specific cflags thing.  i'm sure that it would save me one hell of alot of time.   :Idea: 

----------

## Bob P

 *kimchi_sg wrote:*   

> How about emerging ccache early on in the installation process?
> 
> Ccache is not enabled until you explicitly emerge it, on top of having "ccache" in FEATURES. 

 

hmmm....   that would definitely be worth looking into.  i have a box that is rebuilding from the ground up right now.  i only wish that i had caught this post earlier ...

 *kimchi_sg wrote:*   

>  *slycordinator wrote:*   So if gcc isn't optimized at all and you use it to compile a program using optimized cflags what happens is this:
> 
> gcc creates the optimized binaries but takes longer than optimal to do it. 
> 
> The fun part about using less optimisation is this: You will get to spend more time away from the computer, wondering when on Earth it will ever, ever finish compiling KDE. 

 

sly, kimchi_sg:  those have to be the two best one-liners i've come across in a long time!  :Exclamation: 

----------

## Bob P

 *Heidrun wrote:*   

> shouldn't it be:
> 
> ```
> # By default, boot the second entry.
> 
> ...

 

geez, we're already into the 13th page of comments on the installation method -- i'm surprised that it took this long for somebody to catch that misteak!   :Embarassed: 

the idea was to fall back to the non-framebuffer kernel choice if the frambuffer configuration was borked.  in reality, it would be better to configure a system to fall back to an older version of a kernel (or to genkernel) if your newly compiled kernel borked the system.  at least that's the idea behind the need for a fallback option in grub.conf.

thanks for catching the error.  :Wink: 

----------

## Master One

Well, just an update for those, who care:

After taking some time to study the gcc onlinedocs, I reverted to the following save set of flags for my IBM ThinkPad T42p:

```
CFLAGS="-O2 -march=pentium-m -pipe -fforce-addr -fomit-frame-pointer -fweb"

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

LDFLAGS="-Wl,-O1"
```

The clue is, these few flags most likely will give a much better results, than the formerly used stacked "insane" flags.

I now see the sense of going -O2 instead of -O3, at least one of the "insane" flags had questionable results (-fprefetch-loop-arrays -> "These options may generate better or worse code"), and one definitely broke libs without error on compile (-fvisibility=hidden -> only to be used by developers, at least for now).

I compiled my whole system with these save set of flags, started right from the beginning with Bob P's fabulous installation method, and at the moment I am emerging KDE 3.3.2-r1 (I keep staying on the stable side now, and let others do the KDE3.4.0_rc1 testing).

This time everything looks alright.

----------

## Bob P

 *Master One wrote:*   

> Well, just an update for those, who care:
> 
> After taking some time to study the gcc onlinedocs, I reverted to the following save set of flags for my IBM ThinkPad T42p:
> 
> ```
> ...

 

to reach a high degree of success on a wide variety of platforms, i think that its important to be selective about one's choice of cflags.   fwiw, i'm still not using the insane set of cflags on my system.  i'm still limiting myself to the conservative and performance-enhancing cflags that i've used in the Guide.  although the use of some of those other flags (suggested by kimchi-sg) may be alluring, its important to remember that they can act as a double edged sword.  some of them cause alot of problems -- more problems than they are worth.  

i don't use -funroll-loops, for example.  that flag has acquired a deservedly bad reputation.  -fprefecth-loop-arrays is another one.

i've said it before, and i'll say it again:

 *Stage 1/3 Guide wrote:*   

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

 

these cflags are conservative.  they are extensivley tested and they are proven to be safe.  in the Guide, i have specifically warned people about the need for troubleshooting that would result from using anything other than the recommended flags.  kimchi_sg also made his warnings in bold faced red type.  its really surprising to me that in spite of repeated warnings, people decide to use flags other than those that are recommended.  its as if there's some overpowering vortex that is pulling everyone into the land of the Gentoo Ricer.  not that there's anything wrong with that, of course, as long as the user is willing to accept the responsibility for troubleshooting their own system.  unfortunately, that kind of trouble is going to follow for those that insist on adding to the cflags.  the funny thing is that the problem is completely avoidable, but people just can't seem to resist the temptation to subject themselves to it.

my personal recommendation is to stick with the cflags that are recommended in the guide.  when i wrote the guide, i tested those cflags extensively on a wide variety of PCs.  i performed a large number of installations, and  i got rid of cflags that caused problems.  if the user is going to try out cflags other than those that are listed, they should expect to encounter problems that will require troubleshooting.

----------

## ronvenema

Bob, I can attest that the ccache makes a huge difference in compiling time. I'm in the process of finishing  a new install and Kde compiled in about 1/3 less of the time. :Very Happy: 

----------

## Bob P

i haven't had much opportunity to tinker with ccache much in the past few days, other than to   verify that the cache feature does indeed work when emerging programs.  i haven't had any chance to compare benchmarks with ccache enabled vs. disabled.  (i've been rather busy over the past few days, as i've just acquired a new scanner with automatic document feed, and i've been spending the past few days scanning and shredding documents.  i've already scanned a couple of drawers worth of paper out of my filing cabinet and replaced them with CDs.  WOW!   :Shocked: )

regarding ccache, it would seem a good idea to emerge it early enough in the install process to save you some time in compiling, but late enough in the process that its already been built with a stable toolkit.  for this reason, i'm thinking about adding the following to the guide:

 *New Addition to the Guide wrote:*   

> 7.3.0  Emerge Ccache We'll now emerge the ccache program to help speed-up our compile times. This should markedly reduce the time required to compile programs when the -O2 or -O3 parameters are in use.  
> 
> ```
> # emerge ccache
> ```
> ...

 

Some people might ask why I chose to emerge ccache at this rather late point in the installation instead of emerging it much earlier, say in Section 6.7.3.  Here's the idea that I have about doing it later rather than sooner:

Insofar as I haven't had a chance to actually test build a system using ccache, I am reluctant to recommend emerging ccache as Section 6.7.3 and using it to rebuild the toolkit.  In order to be conservative, I don't think that its a good idea to recommend the use of ccache to build the system toolkit until I've had enough time to prove that it is safe and reliable.  for this reason, I prefer to start off with the recommendation of delaying the emergence of ccache until after the toolkit has been rebuilt;  by doing this we're going to sacrifice some of the potential time-saving during the toolkit build by taking the conservative approach. 

I won't have an opportunity to test build systems both ways (emerging ccache early as Section 6.7.2 and emerging it late as Section 7.3.0).  So I'd appreciate it if somebody with time on their hands could perform installations on two similar systems, side by side, compare the results, and report back to us.

----------

## ronvenema

I can second your idea of adding ccache later after the toolchain has been completed as that's how I did it. My main objective was to use it for all those huge programs like Kde.

I also wanted to mention that Section 6.5 in your example make.conf you show the appropriate entries for ccache but you show ccache_size="512M", but the "bible" shows ccache_size="2G" which is what I used. I assume that you would need the larger value in order to compile programs like Kde.

----------

## ephilli2

I just wanted to thank you for the great install guide.  It went off without a hitch...well almost.  I used gentoo-dev-sources as my kernel which I didn't realize wouldn't work with my reiser4 partitions.  I had used the lxnay RR4 live cd to create the partitions.  I tried nitro, morph, but 2.6.11-love1 was the only one that was able to boot successfully.  At least now I'm more confident about recompiling kernels if not a little exhausted.

ronvenema:  as I understand it ccache is just a bonus feature,  if it finds a piece of code that it has compiled before in the cache it will use that instead of compiling again.  So, the larger the cache, the more likely a piece of code will be found in it, the shorter the compile time.  A huge cache is beneficial to the system as a whole not just for compiling large programs like KDE.

Thanks again Bob P

(edit)

I guess I could have tried using the lxnay cd's kernel by attempting something like this:

http://www.gentoo.org/doc/en/gentoo-x86-tipsntricks.xml#livecd-kernel

I may still try this since they cd was able to get my IPW2200 running ( I haven't attempted this yet on the current install)

----------

## slycordinator

 *kailauro wrote:*   

> Thanks kimchi_sg & slycordinator for your answers.
> 
> I had trouble making a point about something that I have a very simple abstraction about and not that much knowledge. No confusion here.
> 
> Not that many people seem  know what really happens after the source has been sent to compilation. also the toolchain is used to compile the system that includes all kinds of functionality that a computer can possibly have!!

 

Lets assume you were right all along and that only an optimized gcc can create optimized binaries.

NOTE: gcc is a binary.  An optimized gcc is an optimized binary.

So how does one create an optimized gcc?  Based on your assumption this can only be created using an optimized gcc.  So when you have no optimized gcc you can't create one.  But once one magically appears out of nowhere, you can create one.

That clearly doesn't work.  Which means your assumption was false.

 *Quote:*   

> 
> 
> PS. could you also make bzip2 perform at the speed of tar?

 

I doubt it. 

tar is just an archiving utility.  Tar would be like taking 50 pieces of paper and placing them together in one bag.

bzip2 is a compression utility.  Using bzip2 would be like taking those 50 pieces of paper and combining the writing to use less paper.

tar's job seems easier.  Also, bzip2 is slower than some other compression utilities because it does better compression than many.

----------

## Bob P

 *ephilli2 wrote:*   

> ronvenema:  as I understand it ccache is just a bonus feature,  if it finds a piece of code that it has compiled before in the cache it will use that instead of compiling again.  So, the larger the cache, the more likely a piece of code will be found in it, the shorter the compile time.  A huge cache is beneficial to the system as a whole not just for compiling large programs like KDE.

 

i'm no expert about ccache, but i second your thoughts that the necessary code needs to be in the cache for the cache to do us any good!  :Very Happy:   i think that some of the perceived improvements that @ronvenema noticed may not be necessarily real improvements.

remember, for ccache to do anyone any good, the compiled code has to already be in the cache.  in the case where you've already compiled KDE on your PC, if your cache size is large enough, then KDE code is already going to be in the cache.  this means that the second time that you compile KDE, you'll perceive a whopping increase in performance because KDE is already in the cache!  this would definitely NOT be the case when you're compiling KDE for the first time!  for obvious reasons, the 30% reduction in compiling time with/without ccache doesn't translate into a reliable 30% reduction in compile times.

so in the big scheme of things, ccache isn't going to impart HUGE performance improvements in building your gentoo system as you follow the guide -- remember, for the most part, when you're following the guide, you're creating a de novo system installation, and no pre-existing code is going to be in your cache.  this means that the HUGE performance improvement perceived by @ronvenema will only be realized when recompiling code that you've compiled at least once before.

now this is not to say that ccache won't help you when emerging your programs -- if you're using -O3 optimization, for instance, ccache should find the all of the code that its working on in the cache for at least one compiling pass (as long as the value of your cache is nonzero).

at least that's the way i understand it.  but then i don't have any real experience digging into the bowels of ccache, so i could be wrong...  :Rolling Eyes: 

----------

## Bob P

 *slycordinator wrote:*   

> That clearly doesn't work.  Which means your assumption was false.
> 
> 

 

that's a nice  example of applying basic symbolic logic to real life thinking.   :Wink: 

----------

## Bob P

 *ronvenema wrote:*   

> I also wanted to mention that Section 6.5 in your example make.conf you show the appropriate entries for ccache but you show ccache_size="512M", but the "bible" shows ccache_size="2G" which is what I used. I assume that you would need the larger value in order to compile programs like Kde.

 

ron, my choice of 512M was based on the fact that i was building a router on a pentium-class machine in the example used in the guide.  that choice was application-specific for the size of the disk that i had on-hand for that project -- a system upon which a bloated resource hog like KDE would never be installed!  insofar as the Guide is not intended as a Universal Installation Handbook, the value of 512M shouldn't be considered as cast in stone -- users are free to change basic things like cache sizes to suit there individual needs.

----------

## kimchi_sg

Bring on the mayonaise: Optional frills for the install

This is a long post, but it is not the installation tutorial itself. You'll want page 1 for that. This is page 14.  :Razz: 

Part 1: The one one-liner strikes back

1.1 >>> Preamble

Well, I suppose everyone who has read both this tutorial and ali3nx's "stage 1 developer's method" tutorial that preceded it will have noticed that the "gcc-config stress level reduction onliner" from ali3nx's has been broken up into at least 3 one-liners here: one for before updating make.conf, one for after updating make.conf, and one for after "emerge system". Well, here's how to do it ali3nx's way: all in one one-liner!

For those new to this "one-liner" business and wondering how this long command works, it is because the bash shell allows us to chain commands using the && operator. The maximum length of the command is limited to... 65,535 characters. Relax, we are not going to type that many characters in this long command.  :Very Happy: 

Advantage of typing out the most time-consuming commands as a single one-line command:

More time for coffee breaks, walking the dog, eating donuts, etc.

No need to spend as much time waiting for one of the "sub-commands" to complete.

You will feel like a geek for using sed, the command-line text editor. "Look ma, I changed my make.conf with a single command!"  :Razz: 

Pre-requisites for this to work:

A good pair of eyes.

Steady fingers.

Good ambient lighting. Do not do this in a dark room.  :Laughing: 

1.2 >>> How to Transfer this One-liner

I recommend using gpm and links while in the liveCD environment to transfer the text of the one-liner onto the command line. Here's how:

For non-screen users (which means most people):

Press ALT + F2 to switch to console number 2.

Fire up links and navigate from the forums main page down to this post.

```
links forums.gentoo.org
```

Using the mouse, select the first line of the one-liner, in exactly the same way as you select text in any other text editor.

Switch back to the installation console (console number 1) by pressing ALT + F1

If your mouse has 3 or more buttons, middle-click to paste the copied text at the command prompt.

If your mouse has only 2 buttons, click on both buttons at the same time to paste the text.

DO NOT press ENTER yet, the command is still not in its entirety. Insert a space after the pasted text.

Repeat steps 3 to 7 for the remaining lines of the one-liner.

Please triple-check the pasted text to check that it matches exactly what is listed in the one-liner. Switch back to links in console 2 to take a look, if necessary.

Finally, press ENTER to send the one-liner into action.

For users of screen:

Press CTRL + A , c to create a new screen window. (screen is not synonymous with window here, hence the italics)

Fire up links and navigate from the forums main page down to this post.

```
links forums.gentoo.org
```

Scroll the page until all of the one-liner can be seen. Tip: Use the INSERT and DELETE keys to move up and down one line at a time, respectively.

Enter text copy mode with CTRL + A , [

Use the arrow keys to move the cursor until it is under the first character of the one-liner.

Press ENTER. screen will display a confirmatory message in the lower left corner of the screen: "First mark set - column 32 line 34" (your column and line numbers may differ) This means that the starting mark of the selection to be copied has been set.

Extend the selection with the arrow keys, until the entire command has been selected.

Press ENTER again. screen will display another message: "Copied 1116 characters into buffer" (buffer is the linux term for "clipboard").

Since the one-liner is indented by links when it renders the page, we need to trim out the extra spaces and line breaks in the buffer copy.

Press CTRL + A , > (CTRL + A , SHIFT + .) to write the buffer's contents into a temporary file ( /tmp/screen-exchange , according to screen's confirmation).

Using your favourite editor, edit /tmp/screen-exchange to remove all the line breaks and (optionally) extra spaces. The entire text of the file must fit on one line.

Once done, press CTRL + A , < to "slurp" the contents of the file back into the buffer. screen will display: "Slurped 807 characters into buffer". This is the number of characters in the one-liner without extra line breaks and redundant spaces.

Go back to the installation window, which is most likely to be window 0: CTRL + A, 0

Press CTRL + A , ] to paste the edited one-liner at the prompt, ready for execution.

Finally, press ENTER to watch it all take off.  :Very Happy: 

1.3 >>> Public Service Messages

This one-liner is to be entered only right after step 6.7.2 (editing /etc/locales.build)! It will take you all the way to step 8.3 (configuration). That's the most time-consuming part of this tutorial.

This one-liner assumes that you are strictly following the tutorial, and have not set ACCEPT_KEYWORDS="~x86" in /etc/make.conf . It also assumes that you are comfortable with the "extreme" optimised CFLAGS in the edited make.conf, not the milder version.

Remember to replace the "pentium" in "-mtune=pentium" with your own processor type!

Here's the super duper stage 1-on-3 NPTL-enabled turbo-charged one-liner:

(reminder: have you edited /etc/locales.build ?)

```
env-update && source /etc/profile && emerge -C linux-headers && emerge linux26-headers && emerge gcc-config glibc binutils gcc && sed "s/^CFLAGS=\"-O2/CFLAGS=\"-O3 -mtune=pentium -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer/;s/^CXXFLAGS.*}/& -fvisibility-inlines-hidden/" -i /etc/make.conf && gcc-config 2 && env-update && source /etc/profile && emerge glibc binutils gcc portage && emerge -e system && emerge syslog-ng xinetd grub vixie-cron reiserfsprogs sysfsutils udev dhcpcd hotplug coldplug gentoolkit && emerge --nodeps acpid ntp && for x in syslog-ng net.eth0 vixie-cron xinetd sshd hotplug coldplug acpid ntp-client ; do rc-update add $x default ; done && ntpdate -b -u pool.ntp.org && emerge gentoo-dev-sources && rm /usr/src/linux && cd /usr/src && ln -s linux-2.6.10-gentoo-r2 linux
```

Now, you can continue from step 8.3, configuration of udev.  :Very Happy: 

Part 2: Using dispatch-conf

dispatch-conf is a superior program for updating configuration files. man dispatch-conf (once your system is fully installed!) will give more details.

EDIT: Since someone has already spilled half of the beans 2 posts after me, I shall reveal the full details here.

All this is to be done when you are ready to update your configuration files, which means anytime from after "emerge splashutils" to before "rebooting the system".

emerge rcs

Create the /etc/config-archive directory. 

```
mkdir /etc/config-archive
```

Edit /etc/dispatch-conf.conf and change the options as you like. Here's mine:

```
$ cat /etc/dispatch-conf.conf

#

# dispatch-conf.conf

#

# Directory to archive replaced configs

archive-dir=/etc/config-archive

# Use rcs for storing files in the archive directory?

# (yes or no)

# This requires rcs to be emerged beforehand, of course.

use-rcs=yes

# Diff for display

diff="diff -Nu %s %s"

# Pager for diff display

pager="less --no-init --QUIT-AT-EOF"

# Automerge files comprising only CVS interpolations (e.g. Header or Id)

# (yes or no)

replace-cvs=yes

# Automerge files comprising only whitespace and/or comments

# (yes or no)

replace-wscomments=yes

# Automerge files that the user hasn't modified

# (yes or no)

replace-unmodified=yes

# Per-session log file of changes made to configuration files

#log-file=/var/log/dispatch-conf.log
```

Run dispatch-conf

Part 3: Using etc-update

For those who still wish to use etc-update, edit /etc/etc-update.conf to customise this poor program as much as you like. Here's mine, edited to make etc-update use the dialog-driven menu-based interface:

```
$ cat /etc/etc-update.conf

# edit the lines below to your liking

# $Header: /var/cvsroot/gentoo-src/portage/cnf/etc-update.conf,v 1.5.2.1 2004/10/22 16:53:30 carpaski Exp $

# mode - 0 for text, 1 for menu (support incomplete)

# note that you need dev-util/dialog installed

mode="1"

# Whether trivial/comment changes should be automerged

eu_automerge="yes"

# arguments used whenever rm is called

rm_opts="-i"

# arguments used whenever mv is called

mv_opts="-i"

# arguments used whenever cp is called

cp_opts="-i"

# pager for use with diff commands (see NOTE_2)

pager="less"

#pager=""

# vim-users: you CAN use vimdiff for diff_command. (see NOTE_1)

diff_command="diff -uN %file1 %file2"

using_editor=0

#diff_command="vim -d %file1 %file2"

#using_editor=1

# vim-users: don't use vimdiff for merging (see NOTE_1)

merge_command="sdiff -s -o %merged %orig %new"

# EXPLANATION

#

# pager:

#

# Examples of pager usage:

#       pager=""                # don't use a pager

#       pager="less -E" # less

#       pager="more"    # more

#

#

# diff_command:

#

# Arguments:

#       %file1  [REQUIRED]

#       %file2  [REQUIRED]

#

# Examples of diff_command:

#       diff_command="diff -uN %file1 %file2"   # diff

#       diff_command="vim -d %file1 %file2"             # vimdiff

#

#

# merge_command:

#

# Arguments:

#       %orig   [REQUIRED]

#   %new    [REQUIRED]

#       %merged [REQUIRED]

#

# Examples of merge_command:

#       merge_command="sdiff -s -o %merged %old %new"   # sdiff

#

# NOTE_1: Editors such as vim/vimdiff are not usable for the merge_command

# because it is not known what filenames the produced files have (the user can

# choose while using those programs)

# NOTE_2: Make sure pager is set to "" when using an editor as diff_command!
```

Part 4: Using screen to preserve running emerges, your privacy and yesterday's pizza

4.1 >>> Blah, blah, blah

(OK, I admit screen can't preserve pizza. But hey, it still is useful.)

I am wondering why screen does not even get an honourable mention in this tutorial, although ali3nx mentioned it as being very useful. I agree wholeheartedly with him, IMO, screen is really, truly one of the top 10 most useful linux programs. I will let him explain what it is:

 *ali3nx wrote:*   

> 
> 
> Why use Screen Before Installing and Starting Screen 
> 
> -------------------------------------------------------------- 
> ...

 

Users of screen are not afraid of their emerge being interrupted, either by pressing CTRL + C accidentally or their kids banging on the keyboard while they're in the kitchen making coffee. As long as screen is detached or locked, nothing short of a hardware failure or power outage will interrupt any programs running within it.  :Very Happy: 

4.2 >>> Get screen up and Kicking

For best results, start screen as the very, very first command after the liveCD has booted up successfully.

```
# screen
```

screen will start up and retreat quietly to the background, and you will get back a # prompt. You can now proceed normally with the rest of the install. But if you want to know what difference starting screen will make, read on.

To make screen useful, press CTRL + a , ? (that is, press CTRL + a followed by SHIFT + /) for a help page listing some of the things it can do.

Keep in mind that the console window you get right after starting screen is window number 0.

4.3 >>> Honest cheat sheet

However, even I have found the help page a bit cryptic at times, so here it is, the screen cheat sheet, courtesy of kimchi_sg

For brevity's sake, only the options and shortcuts most useful for the liveCD install environment are mentioned.

Caution: If you wish to use the "Lock screen" function, make sure you have assigned root a password before using the function. 

```
# passwd
```

 Otherwise, you will be locked out of your install - not a fun way to end it!  :Rolling Eyes:  This is because the default root password on the liveCD is randomly generated.

4.3.1 >>> Shortcut keys inside of screen

TO ACTIVATE A FUNCTION, PRESS CTRL + A (or CTRL + a), THEN PRESS THE LISTED KEY

KEYS ARE CASE SENSITIVE, a and A do not do the same thing

 *Quote:*   

> 
> 
> (CTRL + A +) Key - Function
> 
> ? - Help screen
> ...

 

4.3.2 >>> Options for starting screen (command-line options)

 *Quote:*   

> 
> 
> -r Reattaches a detached screen. In other words, the detached screen is made active again.
> 
> -RD Most useful for those installing Gentoo over ssh. This will detach screen on the remote system (the one you're installing on) and re-attach it on the local system (the one you're watching the install on).
> ...

 

4.4 >>> Doing the unimaginable - or, exiting screen

There is really no need to terminate screen (I'm not referring to detaching it, but to closing or "exiting" it totally). It will handle all commands silently and invisibly, and springs to attention only when you press CTRL + A followed by any of its shortcut keys.

You can shutdown your computer from within screen. It will exit cleanly, leaving no errors.

But if you really want to close screen, just close all of its windows (use CTRL + a, " to track them down) by typing exit at the prompt in each window.

----------

## ronvenema

I should have explained that you are absolutely right about the ccache being advantageous only after the code was already compiled once. The time savings was realized on the second and subsequent compilings of kde and other programs. I wish that I had benchmarked the difference but at the onset I was skeptical about the usefulness of using the program.

----------

## ephilli2

What's the deal with dispatch-conf?  The first thing I do after a fresh install is emerge rcs and colordiff.  I then set up dispatch-conf to use them.  I think my initial problems when I first started using gentoo were mainly the result of me clobbering config files by using etc-update.

----------

## Bob P

 *kimchi_sg wrote:*   

> Here's the super duper bootstrappy stage 1-on-3 NPTL-enabled turbo-charged one-liner:
> 
> (reminder: have you edited /etc/locales.build ?)
> 
> ```
> ...

 

bootstrap?  technically, we never bootstrap since we started with a stage 3 tarball.  i'm sure that you understand this, but i thought i'd point this out in case there's someone less experienced who gets confused by this:  for the record, we don't bootstrap in using this installation method.

regarding the automation, i guess it was only a matter of time before somebody suggested a way to re-join the 3 separate steps and make a one-liner out of them.  i was thinking that you could accomplish the same thing by making a "make.conf.343" file and using a command like " && cp /etc/make.conf.343 /etc/make.conf &&" within the one-liner as a substitute for Step 2 to join Steps 1 and 3 if you really wanted to rejoin the three steps to automate the process.  i think that this approach would be a little easier for most people to follow than editing the individual CFLAG statements as part of a command line structure.  but  your method is cool, in a very hardcore geek sort of way.   :Wink: 

regarding dispatch-conf, i think dispatch conf is a great option for people that are willing to learn how to use it, but i really haven't given any thought to making it part of the Guide.

----------

## kimchi_sg

 *Bob P wrote:*   

> bootstrap?  technically, we never bootstrap since we started with a stage 3 tarball.

 

The original post has been edited to remove potential confusion.  :Smile: 

Also, CFLAGS post on page 2 edited to remove some controversal flags.

 *Bob P wrote:*   

> regarding the automation, i guess it was only a matter of time before somebody suggested a way to re-join the 3 separate steps and make a one-liner out of them.  i was thinking that you could accomplish the same thing by making a "make.conf.343" file and using a command like " && cp /etc/make.conf.343 /etc/make.conf &&" within the one-liner as a substitute for Step 2 to join Steps 1 and 3 if you really wanted to rejoin the three steps to automate the process.  i think that this approach would be a little easier for most people to follow than editing the individual CFLAG statements as part of a command line structure.  but  your method is cool, in a very hardcore geek sort of way.  

 

You didn't comment on the easing up on repetitive rc-update commands using for loop. It seems you copied that one-liner from ali3nx, whom I suspect (despite his "NPTL on stage 1" wisdom) is not a bash scripter at all.

P.S. It really is a torture to type in 9 rc-update commands consecutively with only changes in the service name. Please consider replacing the separate rc-update commands with the for loop.

More from the "foolish changes to the tutorial" department:

If you move all the editing of make.conf, locales.build ( both in /etc ), package.keywords and package.use ( both in /etc/portage ) to just BEFORE chrooting, you can extend my one-liner to cover ALL the steps from after "chroot" to "updating the kernel symlink".  :Wink: 

 *Bob P wrote:*   

> regarding dispatch-conf, i think dispatch conf is a great option for people that are willing to learn how to use it, but i really haven't given any thought to making it part of the Guide.

 

That's really bad. Theoretically, with dispatch-conf, you will never lose a config file again.  :Razz: 

But for those dyed-in-the-wool etc-update users, I have not forgotten you. I've inserted a part on tweaking etc-update.  :Wink: 

----------

## slycordinator

 *Bob P wrote:*   

>  *slycordinator wrote:*   That clearly doesn't work.  Which means your assumption was false.
> 
>  
> 
> that's a nice  example of applying basic symbolic logic to real life thinking.  

 

Yep.  I love reducing things to just that.

That's one of the many reasons I'm a geek.

----------

## Infra

I'm testing this on AMD64 arch now, i'll post my results when it's ready.

----------

## Bob P

 *kimchi_sg wrote:*   

>  *Bob P wrote:*   regarding the automation, i guess it was only a matter of time before somebody suggested a way to re-join the 3 separate steps and make a one-liner out of them.  i was thinking that you could accomplish the same thing by making a "make.conf.343" file and using a command like " && cp /etc/make.conf.343 /etc/make.conf &&" within the one-liner as a substitute for Step 2 to join Steps 1 and 3 if you really wanted to rejoin the three steps to automate the process.  i think that this approach would be a little easier for most people to follow than editing the individual CFLAG statements as part of a command line structure.  but  your method is cool, in a very hardcore geek sort of way.   
> 
> You didn't comment on the easing up on repetitive rc-update commands using for loop. It seems you copied that one-liner from ali3nx, whom I suspect (despite his "NPTL on stage 1" wisdom) is not a bash scripter at all.

 

yes, the rc-update commands do bear a more than coincidental resemblance to the ali3nx Stage 1 install Guide.  :Wink:   as i had mentioned in the intro to the Stage 1/3 Guide, i protyped my installation method to build a system that would have similar functionality (ie: emerges the same basic system programs) to his Stage 1 install, but added the improved performance an optimized toolkit and the added robustness of building upon a Stage 3 tarball.  so yes, in a fit of laziness, the repetitive rc-update commands were lifted almost directly from his install guide.

i really do like your for loop.   :Cool:   it addresses the update problem in an elegant way, and it will definitely find its way into the guide.  insofar as this is an advanced installation method, i like the idea of using advanced shell techniques.   :Wink:   but because the guide has become a n00b magnet, i don't think it would be a great idea to completely remove the redundant commands, as they make it very clear to the less sophisticated user what is going on.  i think that i will provide the for loop as a 3rd alternative.  its great code, and i think that its one of the coolest additions to the guide that have been suggested so far.  :Idea: 

 *Quote:*   

> P.S. It really is a torture to type in 9 rc-update commands consecutively with only changes in the service name. Please consider replacing the separate rc-update commands with the for loop.

 

well, it is torture if your're typing a one-liner, but its very easy if you're typing at the bash prompt using the up-arrow key, so that you only have to change the service name.  for those who prefer the one-liner approach, the for loop is a very nice idea.

----------

## Bob P

 *kimchi_sg wrote:*   

> More from the "foolish changes to the tutorial" department:
> 
> If you move all the editing of make.conf, locales.build ( both in /etc ), package.keywords and package.use ( both in /etc/portage ) to just BEFORE chrooting, you can extend my one-liner to cover ALL the steps from after "chroot" to "updating the kernel symlink". 

 

well, if we decide to go that route, we're talking about changing the focal point of the guide;  right now the focus of the guide is to educate people on how to rebuild their toolkit and their system files.  as part of that objective, the guide is written in a logical order that is easy for the user to follow.  if we change the focus of the guide so that it is primarily based on performing an unattended installation, then the guide will become somewhat less intuitive and somewhat harder to follow.  that is not necessarily a bad thing.  i'll have to think about it a little.  have you given any thought to just writing a big bash script that completely installs Gentoo for us once you've booted the Live CD?   :Twisted Evil: 

i really won't have alot of time to do a major revision to the guide until the tax season is over here in the U.S.  i have a couple of complete system rebuilds scheduled to take place after the tax season, and that would provide a great opportunity to revise the installation method and update the guide.

----------

## kimchi_sg

More magic on its way... The post at the top of this page has been updated massively to include the usage of screen (IMO, one of the 10 wonders of the GNU/linux world  :Razz: ) in the install process.  :Very Happy: 

 *Bob P wrote:*   

> have you given any thought to just writing a big bash script that completely installs Gentoo for us once you've booted the Live CD? 

 

I might just get around to writing an install script that takes care of everything. I just might. Maybe it should be called G.L.I.S. 2.  :Twisted Evil: 

But alas, my exams are coming up in a month's time.  :Sad: 

----------

## Bob P

 *kimchi_sg wrote:*   

> I am wondering why screen does not even get an honourable mention in this tutorial, although ali3nx mentioned it as being very useful. I agree wholeheartedly with him, IMO, screen is really, truly one of the top 10 most useful linux programs. 

 

screen is good if you need it, but as i was writing the Guide i really didn't think that the average user performing a Gentoo install really needs it to complete a successful installation.  

sure, creen is great if you're using ssh to hook up to a remote PC and you want to perform remote administration, but i didn't think that was the typical situation for a Gentoo user performing an install.  

again, the focus of this Guide is limited to how to rebuild an optimized toolkit on top of a very stable Gentoo base system.  its not really about all of the other cool things that can be done with linux.

----------

## Infra

Okay, 

I have finished the installation with my 64bit Dual Xeon, and it's working great.

So this guide is working great for amd64, ofcourse you won't have to use "unstable" branch. With amd64 it's just pain in the a**  :Smile: 

Thanks Bob for this great guide, i'm going to use this in future also.

----------

## kimchi_sg

 *Bob P wrote:*   

> again, the focus of this Guide is limited to how to rebuild an optimized toolkit on top of a very stable Gentoo base system.  its not really about all of the other cool things that can be done with linux.

 

True, but just as a good movie has to be watched with a big bucket of popcorn and a giant coke to boot, so a good install method should be accompanied by some frills to make it easier.  :Very Happy: 

I've put a big "Optional" header there, to remind people of the "Extra"-ness of these things. Yes, even the usage of dispatch-conf.  :Razz: 

 *Bob P wrote:*   

> sure, screen is great if you're using ssh to hook up to a remote PC and you want to perform remote administration, but i didn't think that was the typical situation for a Gentoo user performing an install.

 

It is great not only for that purpose... but I shall not drag the debate further.  :Smile: 

I was trying in my post to highlight those features that would work great even on non-remote installations, hence the title of that section.

----------

## Bob P

 *kimchi_sg wrote:*   

> I might just get around to writing an install script that takes care of everything. I just might. Maybe it should be called G.L.I.S. 2. 
> 
> But alas, my exams are coming up in a month's time. 

 

yes, time is our worst enemy.  you know, it would really be cool to have one big bash script that you could just cut and paste to do the entire installation.  it wouldn't be as readable as the guide, but it would be very cool.  :Cool: 

btw, the Guide now has both ccache and the for loop.   :Wink: 

----------

## kimchi_sg

Gahhh!!! Just spotted the killer mistake in my for loop! It should read 

```
do rc-update add $x default
```

 instead of 

```
do rc-update $x
```

 :Embarassed: 

The original post has been updated.

(File this in the "Growing pains of a budding bash scripter" file...  :Sad:  )

----------

## Bob P

 *kimchi_sg wrote:*   

> Gahhh!!! Just spotted the killer mistake in my for loop! It should read 
> 
> ```
> do rc-update add $x default
> ```
> ...

 

i thought it looked funny without the default runlevel statement, but i have to admit, i didn't actually try it.  i hate typos.   :Sad: 

----------

## Bob P

 *Infra wrote:*   

> I have finished the installation with my 64bit Dual Xeon, and it's working great.
> 
> So this guide is working great for amd64, ofcourse you won't have to use "unstable" branch. 

 

this makes me wonder if most of the develpers are using AMD 64 boxen.   :Exclamation: 

----------

## kimchi_sg

 *Bob P wrote:*   

> this makes me wonder if most of the develpers are using AMD 64 boxen.  

 

Or maybe the AMD64 devs are just quicker to unmask packages into the stable branch.  :Cool: 

----------

## DrWoland

So... another success  :Razz:  I think NOW I have my system just how I want it.

----------

## kimchi_sg

@Bob P:

Just a passing thought: Will you be updating this guide as and when 2005.0 becomes available?

It seems that the final release will almost certainly be ready in a couple of weeks from now at the very latest. I'm expecting it not more than 7 days from now.  :Very Happy:  If not for the show-stopper security bugs which prompted a "security rebuild", we'd all be downloading 2005.0 liveCD ISOs by now.  :Razz: 

You may want to put off some of the system rebuilds to test out the effect of the changes in 2005.0 on the install tutorial. With kernel 2.6 sources and headers becoming the default almost everywhere, this will be a exciting time on the Gentoo battlefront.  :Smile: 

----------

## mridle

Hi Bob

Been using Gentoo for several months now and was feeling like upgrading gcc - so I printed your excellent guide and had fun rebuilding my system. However, I was unable to boot my system afterwards. As suggested in another thread I copied over /proc/mounts to /etc mtab, which solved the problem. I don't know if it's a general problem, or it was just my kernel/system that was tricky - but maybe a heads up in the guide would be nice.

Apart from that, I now have a great running system including X and all the apps I would ever want.

/idle

----------

## kimchi_sg

 *mridle wrote:*   

> I printed your excellent guide and had fun rebuilding my system. However, I was unable to boot my system afterwards. As suggested in another thread I copied over /proc/mounts to /etc mtab, which solved the problem. I don't know if it's a general problem, or it was just my kernel/system that was tricky - but maybe a heads up in the guide would be nice.

 

I concur. The x86 baselayout is to blame, it seems.

If using all unstable packages, this problem does not happen, but it happened to me too on my last install, when I decided to stick with the stable branch for the very first time.  :Sad: 

----------

## mridle

oh - so the secret to a stable system is to choose the unstable branch  :Shocked: 

Well it's not really a big problem - when you find out what's wrong. But I'll admit, that I got a little worried that I somehow had borked my partitions, when it failed booting...

----------

## kimchi_sg

 *mridle wrote:*   

> oh - so the secret to a stable system is to choose the unstable branch

 

Says who?

The moral of the story: ~x86 may be as good as x86 some of the time, and x86 is better than ~x86 most of the time. I have digressed enough.  :Razz: 

----------

## Master One

 *kimchi_sg wrote:*   

>  *mridle wrote:*   oh - so the secret to a stable system is to choose the unstable branch 
> 
> Says who? The moral of the story: ~x86 may be as good as x86 some of the time, and x86 is better than ~x86 most of the time. I have digressed enough. 

 

I think, it's generally better to stick with x86, and to only fetch needed packages (like the actual baselayout) from the ~x86 branch. Those packages to put with "=" and version-number into /etc/portage/package.keywords (like I did with the toolkit packages), so if it's working this way, you will not have to care until the next x86 release of these packages (otherwise you most likely will have to follow a lot of updates in the ~x86 branch, until the next x86 release).

----------

## gonEH

Good for me!!  :Laughing: 

----------

## Bob P

 *kimchi_sg wrote:*   

> @Bob P:
> 
> Just a passing thought: Will you be updating this guide as and when 2005.0 becomes available?
> 
> 

 

yes, that's the plan.  :Very Happy: 

but before we go jumping off of that cliff, have you verified that 2005.0 Stage 1 tarballs have not been updated to solve the only two issues which make the Stage 1/3 installation method necessary???  if they've fixed the 2005.0 Stage 1 Tarballs so that /var/db/pkg lists all of the packages, and if the circular dependencies in the base system have been fixed, there's really no point in using the Stage 1/3 installation method with 2005.0.

----------

## Bob P

 *kimchi_sg wrote:*   

> 1.2 >>> How to Transfer this One-liner
> 
> I recommend using gpm and links while in the liveCD environment to transfer the text of the one-liner onto the command line. Here's how:
> 
> For non-screen users (which means most people):
> ...

 

the typical user who's booting from the Live CD doesn't have an active mouse, does he?  in any installation where i've booted from the live CD onto a blank system, there's no PS/2 mouse support.  so although you can use ALT-F2 to go to the other console, and you can use links to navigate to the forum page, you can't use the mouse to cut and paste text -- unless i'm missing something that's really blatantly obvious...  :Embarassed: 

just for reference, i have booted a Live CD to install Gentoo on a blank system, and I'm at Section 6.2.  i was hoping to cut and paste a big one liner before chrooting.  unfortunately, there's NO mouse support...  

come to think of it, i've never had mouse support until I've gotten to X11.  like i said before, if you're getting mouse support within the live CD environment, then i must be missing something that i shouldn't...  :Embarassed: 

----------

## Bob P

 *gonEH wrote:*   

> Good for me!! 

 

cute dog.  bichon?

----------

## kimchi_sg

 *Bob P wrote:*   

> the typical user who's booting from the Live CD doesn't have an active mouse, does he?  in any installation where i've booted from the live CD onto a blank system, there's no PS/2 mouse support. ... 
> 
> just for reference, i have booted a Live CD to install Gentoo on a blank system, and I'm at Section 6.2.  i was hoping to cut and paste a big one liner before chrooting.  unfortunately, there's NO mouse support...  
> 
> come to think of it, i've never had mouse support until I've gotten to X11.  like i said before, if you're getting mouse support within the live CD environment, then i must be missing something that i shouldn't... 

 

Hmm... the gpm service is included on the liveCD. It started up for me on my very first install, otherwise I would not have noticed that the liveCD has mouse support.  :Cool: 

Maybe it simply didn't start automatically for some reason, in this case a 

```
/etc/init.d/gpm start
```

 will start it.  :Smile: 

----------

## gonEH

 *Bob P wrote:*   

> cute dog.  bichon?

 

She is Maltese dog.  :Smile: 

----------

## Bob P

 *kimchi_sg wrote:*   

> Hmm... the gpm service is included on the liveCD. It started up for me on my very first install, otherwise I would not have noticed that the liveCD has mouse support. 
> 
> Maybe it simply didn't start automatically for some reason, in this case a 
> 
> ```
> ...

 

that's funny.  i've installed gentoo on a whole bunch of PCs, and I've never had GPM detect the mouse at startup.  oh well...

i tried starting the service manually and i got an error when trying to use a simple "gpm start" command:

```
/etc/init.d/gpm start

O0o.oops(): [gpn.c(947)]: Please use -m /dev/mouse -t protocol
```

for some reason it seems that gpm is having trouble finding the mouse device.  maybe this is why it never started on any of my PCs when booting from the live CD.   :Confused: 

i was able to get it running by changing the path for the mouse device using the following command:

```
gpm -m /dev/input/mice -t ps2
```

thanks -- i learned something useful today.  the cut and paste feature will be useful.  :Wink:   i only wish that i had found this answer before i had manually typed that painfully long one-liner!  :Mad: 

----------

## Genia4

Hi

I've read through this intallation method and I don't understand how it can work.

Isn't stage 3 built from stage 1 by the gentoo developers?

If it isn't, how is that possible, they must start from somewhere...

If it is, then it also started with an empty /var/db/pkg, and also was not cleaned by portage, so the whole installation method does not make sense.

I would appreciate an explanation.

Thanks in advance,

Genia

----------

## kimchi_sg

 *Genia4 wrote:*   

> If it is, then it also started with an empty /var/db/pkg, and also was not cleaned by portage, ...

 

... so the whole of your post does not make sense.  :Laughing: 

It does not matter what the Stage 3 tarball started life as, all that matters to us users is that when we download it now, it has a complete /var/db/pkg . This the Stage 1 does not have.

In other words, any /var/db/pkg problems with Stage 3 are strictly the developers' hot potato, not ours to handle. We will never see any of these problems.

----------

## Genia4

 *kimchi_sg wrote:*   

>  *Genia4 wrote:*   If it is, then it also started with an empty /var/db/pkg, and also was not cleaned by portage, ... 
> 
> ... so the whole of your post does not make sense. 
> 
> It does not matter what the Stage 3 tarball started life as, all that matters to us users is that when we download it now, it has a complete /var/db/pkg . This the Stage 1 does not have.
> ...

 

Then why not start with a stage1, emerge the toolchain maybe 3 times or something and have a complete /var/db/pkg?

Is the reason for using stage3 based on saving the emerge time of another toolchain pass?

I kinda understand now, but still it's kinda weird. Also, why in like <someamount> of years nobody has thought of this installation method?

I hope I'm making more sense now  :Smile: 

----------

## kimchi_sg

 *Genia4 wrote:*   

>  *kimchi_sg wrote:*   In other words, any /var/db/pkg problems with Stage 3 are strictly the developers' hot potato, not ours to handle. We will never see any of these problems. 
> 
> Then why not start with a stage1, emerge the toolchain maybe 3 times or something and have a complete /var/db/pkg?

 

Because you will not get a complete /var/db/pkg by doing so! Emerging the toolchain a thousand times will not contribute to the completeness of /var/db/pkg.

You can indeed get a similar system by doing a Stage 1 install - if you love to troubleshoot the problems caused by having an incomplete /var/db/pkg. Just look in the Installing Gentoo forum for all those posts with, say, "ncurses fails on Stage 1 install" or "circular perl dependency during bootstrap.sh". I hope you get the idea of Stage 1's deficiencies here. Our method is superior, unless you love practising troubleshooting skills.  :Very Happy: 

 *Genia4 wrote:*   

> Is the reason for using stage3 based on saving the emerge time of another toolchain pass?

 

No, no, no!

In fact, we compile the toolchain at least 3 times over, first with gcc-3.3.4, then with gcc-3.4.3 and finally one more time during emerge -e system. This is more convoluted than a plain Stage 1 and will take a longer, not shorter, time. In fact, if you read the very first paragraph of the tutorial carefully,

 *Bob P wrote:*   

> The amount of time required for you to complete this type of installation will equal or exceed that of any other Gentoo installation method. ... It will prove especially painful for users who plan to install Gentoo old hardware.

 

FYI, bootstrapping on a Stage 1 compiles toolchain only 2 times, once during the running of bootstrap.sh and then again during emerge system.

 *Genia4 wrote:*   

> I kinda understand now, but still it's kinda weird.

 

I do not think you "kinda understand now"... your reply seems more confused than your first post. But read, read, install and you will be enlightened.  :Laughing: 

 *Genia4 wrote:*   

> Also, why in like <someamount> of years nobody has thought of this installation method?

 

Because the devs like to hide secrets from mortals?  :Razz: 

----------

## Genia4

 *Quote:*   

> I do not think you "kinda understand now"... your reply seems more confused than your first post. But read, read, install and you will be enlightened. Laughing 

 

Ok, now I do actually.

Somehow, I've never ever had problems with stage1, and I did it about 3 or 4 times. Never had circular deps, or failed builds.

But now i understand what this guide is trying to accomplish. You want to give people the optimizations of stage 1 but without having to troubleshoot all the possible problems of stage1, right?

If it is so, then this guide is great, I'm going to install gentoo in a day or two, and I'm definely going to try this method out, maybe then I'll finally understand it completely

Thanks for you help kimchi_sg,

Genia

----------

## Bob P

 *Genia4 wrote:*   

> I've read through this intallation method and I don't understand how it can work.
> 
> Isn't stage 3 built from stage 1 by the gentoo developers?
> 
> If it isn't, how is that possible, they must start from somewhere...
> ...

 

if you're truly curious, then my recommendation would be to view the actual contents of /var/db/pkg in the various tarballs and see the answer youself.  no amount of explaining on our part will amount to anything more than handwaving.  if you want to see the answer spelled-out clearly, a peek at the contents of the Stage 1 Tarball and comparing it to the contents of the Stage 3 tarball will provide you with an unequivocal answer.  we can wave our hands and talk about what the differences are, but if you want to see the real answer, there is no more authorative source than the tarballs themselves.

----------

## Bob P

 *Genia4 wrote:*   

> Somehow, I've never ever had problems with stage1, and I did it about 3 or 4 times. Never had circular deps, or failed builds.
> 
> But now i understand what this guide is trying to accomplish. You want to give people the optimizations of stage 1 but without having to troubleshoot all the possible problems of stage1, right?

 

if you have never had problems with a Stage 1 installation, than you are truly a very, very lucky man.  I have NEVER been able to get through a Stage 1 installation without running into circular dependency issues, and I have NEVER had a Stage 1 installation  that didn not eventually fall to its knees because of the /var/db/pkg issues.  

The circular dependency issues are ones that even the newest of Gentoo users will recognize during the installation process.  Unfortunatly, the /var/db/pkg problems often crop up later, and don't always get recognized for what they are.

In regard to what this guide is trying to accomplish, the objectives are spelled out very clearly on Page 1.

----------

## Bob P

 *kimchi_sg wrote:*   

> Here's the super duper stage 1-on-3 NPTL-enabled turbo-charged one-liner:
> 
> (reminder: have you edited /etc/locales.build ?)
> 
> ```
> ...

 

kimchi-sg, i just thought i'd give you some feedback on the big one liner.  i started mine rolling before i had the mouse problem solved, so i had to type in manually.   :Sad: 

because i'm re-installing a Stage 1/3 on a system that previously held a Stage 1 install, I've left the kernel configuration steps out of the one-liner.  i also made a change in how the contents of make.conf get updated.  instead of using your cool (dare i say g33kish?) method of editing the CFLAGS on the command line, I took a simpler approach -- before starting the one-liner, I created a make.conf.334 file (optimized for GCC 3.3.4) and a make.conf.343 file (optimized for GCC 3.4.3).   this way i was able to make all sorts of detailed changes to the make.conf files to fine-tune them for each stage of the installation process, add USE flags, etc.  then, when switching the gcc compilers, i just copied the new version of make.conf over the old one.  the biggest difference in this approach is that the one-liner is less typographically complicated and you're able to isolate the changes that are made to make.conf from appearing on the command line.  here's the one-liner that i used:

```
env-update && source /etc/profile && emerge -C linux-headers && emerge linux26-headers gcc-config glibc binutils gcc && cp /etc/make.conf.343 /etc/make.conf && gcc-config 2 && env-update && source /etc/profile && emerge glibc binutils gcc portage && emerge -e system && emerge ccache syslog-ng xinetd grub vixie-cron reiserfsprogs sysfsutils udev dhcpcd hotplug coldplug gentoolkit && emerge --nodeps acpid ntp && for x in ccache syslog-ng net.eth0 vixie-cron xinetd sshd hotplug coldplug acpid ntp-client ; do rc-update add $x default ; done && ntpdate -b -u pool.ntp.org 
```

i trimmed off the following part because i kept the /boot partition from my previous gentoo installation and i'll be skipping the kernel configuration steps:

```
&& emerge gentoo-dev-sources && rm /usr/src/linux && cd /usr/src && ln -s linux-2.6.10-gentoo-r2 linux
```

the big one-liner definitely does free the user from alot of seat-time during the installation process.  for this reason, i'm thinking that it would be a great idea to append the big one-liner to the installation guide, so that users who understand the guide and don't need to have the procedure broken up in order to understand it have the option of the one-liner approach.   :Wink: 

----------

## Bob P

 :Exclamation:  PDF Updated   :Exclamation: 

Updated to match the on-line guide as of March 08, 2005.

----------

## juazp

worked fine for my amd64 with the arch modifications etc . thx alot =)

*well except for fb / splash , even tho it emerges fine etc it simply doesnt show up when i boot , even the res is the default sucky one*

----------

## kimchi_sg

Warning: 2 long directory lists ahead!  :Razz: 

2005.0 STAGE 1 tarball preliminary analysis

(This is initially the content of a PM from me to Bob, but the news is so good that IMO everyone who is considering a Stage 1-on-3 ought to give this a thought.  :Very Happy:  )

I have just downloaded a 2005.0 stage 1 tarball (snapshot dated 20050110 downloaded from ftp.isu.edu.tw/pub/Linux/Gentoo/experimental/stages/x86 ) and opened it up in Ark, and it looks promising! The file is 12.8MB, which is about 3MB bigger than the 2004.3 stage1ball. Here is the contents of /var/db/pkg on the 2005.0 stage 1 tarball (edited to show only the package-level directories):

```

drwxr-xr-x root/root         0 2005-01-13 01:08:58 ./var/db/pkg/

drwxr-xr-x root/root         0 2005-01-13 01:08:57 ./var/db/pkg/sys-apps/

drwxr-xr-x root/root         0 2005-01-13 01:08:30 ./var/db/pkg/sys-apps/debianutils-1.16.7-r4/

drwxr-xr-x root/root         0 2005-01-13 01:08:32 ./var/db/pkg/sys-apps/diffutils-2.8.7/

drwxr-xr-x root/root         0 2005-01-13 01:06:30 ./var/db/pkg/sys-apps/baselayout-1.9.4-r6/

drwxr-xr-x root/root         0 2005-01-13 01:08:29 ./var/db/pkg/sys-apps/coreutils-5.2.1-r2/

drwxr-xr-x root/root         0 2005-01-13 01:08:34 ./var/db/pkg/sys-apps/findutils-4.1.20-r1/

drwxr-xr-x root/root         0 2005-01-13 01:08:33 ./var/db/pkg/sys-apps/file-4.12/

drwxr-xr-x root/root         0 2005-01-13 01:08:42 ./var/db/pkg/sys-apps/portage-2.0.51-r3/

drwxr-xr-x root/root         0 2005-01-13 01:08:55 ./var/db/pkg/sys-apps/sed-4.0.9/

drwxr-xr-x root/root         0 2005-01-13 01:08:37 ./var/db/pkg/sys-apps/gawk-3.1.3-r1/

drwxr-xr-x root/root         0 2005-01-13 01:08:39 ./var/db/pkg/sys-apps/grep-2.5.1-r6/

drwxr-xr-x root/root         0 2005-01-13 01:08:41 ./var/db/pkg/sys-apps/net-tools-1.60-r9/

drwxr-xr-x root/root         0 2005-01-13 01:08:40 ./var/db/pkg/sys-apps/less-382-r2/

drwxr-xr-x root/root         0 2005-01-13 01:08:57 ./var/db/pkg/sys-apps/texinfo-4.7-r1/

drwxr-xr-x root/root         0 2005-01-13 01:07:34 ./var/db/pkg/sys-kernel/

drwxr-xr-x root/root         0 2005-01-13 01:07:33 ./var/db/pkg/sys-kernel/linux26-headers-2.6.8.1-r1/

drwxr-xr-x root/root         0 2005-01-13 01:08:08 ./var/db/pkg/sys-libs/

drwxr-xr-x root/root         0 2005-01-13 01:07:37 ./var/db/pkg/sys-libs/glibc-2.3.4.20040808-r1/

drwxr-xr-x root/root         0 2005-01-13 01:08:04 ./var/db/pkg/sys-libs/ncurses-5.4-r5/

drwxr-xr-x root/root         0 2005-01-13 01:08:08 ./var/db/pkg/sys-libs/zlib-1.2.1-r3/

drwxr-xr-x root/root         0 2005-01-13 01:08:02 ./var/db/pkg/app-arch/

drwxr-xr-x root/root         0 2005-01-13 01:08:00 ./var/db/pkg/app-arch/ncompress-4.2.4-r1/

drwxr-xr-x root/root         0 2005-01-13 01:08:02 ./var/db/pkg/app-arch/tar-1.14/

drwxr-xr-x root/root         0 2005-01-13 01:07:42 ./var/db/pkg/app-arch/bzip2-1.0.2-r3/

drwxr-xr-x root/root         0 2005-01-13 01:07:59 ./var/db/pkg/app-arch/gzip-1.3.5-r4/

drwxr-xr-x root/root         0 2005-01-13 01:08:05 ./var/db/pkg/app-editors/

drwxr-xr-x root/root         0 2005-01-13 01:08:05 ./var/db/pkg/app-editors/nano-1.3.4/

drwxr-xr-x root/root         0 2005-01-13 01:08:06 ./var/db/pkg/app-shells/

drwxr-xr-x root/root         0 2005-01-13 01:08:06 ./var/db/pkg/app-shells/bash-2.05b-r9/

drwxr-xr-x root/root         0 2005-01-13 01:08:09 ./var/db/pkg/dev-python/

drwxr-xr-x root/root         0 2005-01-13 01:08:09 ./var/db/pkg/dev-python/python-fchksum-1.7.1/

drwxr-xr-x root/root         0 2005-01-13 01:08:14 ./var/db/pkg/dev-lang/

drwxr-xr-x root/root         0 2005-01-13 01:08:13 ./var/db/pkg/dev-lang/python-2.3.4/

drwxr-xr-x root/root         0 2005-01-13 01:08:27 ./var/db/pkg/net-misc/

drwxr-xr-x root/root         0 2005-01-13 01:08:26 ./var/db/pkg/net-misc/rsync-2.6.3/

drwxr-xr-x root/root         0 2005-01-13 01:08:27 ./var/db/pkg/net-misc/wget-1.9-r2/

drwxr-xr-x root/root         0 2005-01-13 01:09:16 ./var/db/pkg/sys-devel/

drwxr-xr-x root/root         0 2005-01-13 01:09:03 ./var/db/pkg/sys-devel/flex-2.5.4a-r5/

drwxr-xr-x root/root         0 2005-01-13 01:09:01 ./var/db/pkg/sys-devel/bison-1.875/

drwxr-xr-x root/root         0 2005-01-13 01:09:07 ./var/db/pkg/sys-devel/gcc-config-1.3.8-r3/

drwxr-xr-x root/root         0 2005-01-13 01:09:00 ./var/db/pkg/sys-devel/m4-1.4.1/

drwxr-xr-x root/root         0 2005-01-13 01:08:58 ./var/db/pkg/sys-devel/binutils-2.15.90.0.1.1-r3/

drwxr-xr-x root/root         0 2005-01-13 01:09:12 ./var/db/pkg/sys-devel/gettext-0.12.1-r2/

drwxr-xr-x root/root         0 2005-01-13 01:09:13 ./var/db/pkg/sys-devel/make-3.80-r1/

drwxr-xr-x root/root         0 2005-01-13 01:09:10 ./var/db/pkg/sys-devel/gcc-3.3.4-r1/

drwxr-xr-x root/root         0 2005-01-13 01:09:16 ./var/db/pkg/sys-devel/patch-2.5.9/

```

For a total of 35 "listed as installed" packages.

And the corresponding /var/db/pkg on a 2004.3 Stage 1 tarball:

```

drwxr-xr-x root/root         0 2004-10-28 05:40:29 ./var/db/pkg/

drwxr-xr-x root/root         0 2004-10-28 05:40:29 ./var/db/pkg/sys-devel/

drwxr-xr-x root/root         0 2004-10-28 05:39:52 ./var/db/pkg/sys-devel/binutils-2.14.90.0.8-r1/

drwxr-xr-x root/root         0 2004-10-28 05:40:00 ./var/db/pkg/sys-devel/gcc-3.3.4-r1/

drwxr-xr-x root/root         0 2004-10-28 05:39:57 ./var/db/pkg/sys-devel/gcc-config-1.3.6-r3/

drwxr-xr-x root/root         0 2004-10-28 05:40:29 ./var/db/pkg/sys-apps/

drwxr-xr-x root/root         0 2004-10-28 05:38:34 ./var/db/pkg/sys-apps/baselayout-1.9.4-r6/

```

For a total of 4 "listed as installed" packages.

Looks rather lean by comparison, isn't it?

Conclusion: It looks like the full /var/db/pkg is included with 2005.0 stage 1 tarballs. And hence the Stage 1-on-3 install almost certainly will become obsolete with the advent of 2005.0.  :Smile: 

I'm very tempted to switch to the 2005.0 CD and tarballs for installation from now on. They already look good enough to eat off of.  :Razz: 

----------

## Bob P

 *kimchi_sg wrote:*   

> Conclusion: It looks like the full /var/db/pkg is included with 2005.0 stage 1 tarballs. And hence the Stage 1-on-3 install almost certainly will become obsolete with the advent of 2005.0. 
> 
> I'm very tempted to switch to the 2005.0 CD and tarballs for installation from now on. They already look good enough to eat off of. 

 

yes, kimchi_sg and i have been PM'ing each other about whether or not there's a need to update the Stage 1/3 installation method to work with the 2005.0 release of Gentoo.  although he had suggested some changes related to the inclusion of new linux headers in 2005.0, i've been wondering whether the Stage 1/3 installation method would even remain relevant if 2005.0 is built the way i think it should be.

like i've been saying for a looooong time, the Stage 1/3 installation method is nothing more than a kludge/workaround to eliminate some of the problems that are inherent in the 2004.3 Stage 1 tarball.  if the 2005.0 tarballs are made the way they should be, the Stage 1 on Stage 3 tarball installation method will become irrelevant.

in looking at the output from the 2005.0 Stage 1 Tarball, it certainly does look more complete than the 2004.3 Stage 1 tarball.  i think that the best test, though, would be to compare the contents of /var/db/pkg between the 2005.0 Stage 1 and 2005.0 Stage 3 tarballs.

the new 2005.0 Stage 1 tarball is indeed looking better than the old one.  i haven't put any effort into working on adapting the Stage 1/3 guide to 2005.0 because I've been anticipating that it would become unnecessary with the advent of a "proper" 2005.0 Stage 1 tarball.

Has anyone actually tried a Stage 1 install using the 2005.0-rc5 betas to determine whether both the /var/db/pkg info is complete, and the circular dependency issues have all been resolved?

----------

## Sheepdogj15

Hey Bob, i was watching the text from some install scroll by, and i noticed one line saying something about an "nptlonly" USE flag. I was just curious if you were familiar with it, and if so if you would recommend having it in one's use flags. i didn't catch what all it was supposed to do, so i figured i'd pester you.

----------

## Sheepdogj15

 *juazp wrote:*   

> worked fine for my amd64 with the arch modifications etc . thx alot =)
> 
> *well except for fb / splash , even tho it emerges fine etc it simply doesnt show up when i boot , even the res is the default sucky one*

 

i had the same problem, as i mentioned earlier. yeah, other than that the stage 1 on 3tb works well on amd64.

did you remember to have "multilib" in your USE flags before emergeing gcc? i ask just in case, as it is extremely handy on amd64 and is easy to forget.

----------

## Bob P

 *Sheepdogj15 wrote:*   

> Hey Bob, i was watching the text from some install scroll by, and i noticed one line saying something about an "nptlonly" USE flag. I was just curious if you were familiar with it, and if so if you would recommend having it in one's use flags. i didn't catch what all it was supposed to do, so i figured i'd pester you.

 

<rant>

yes, you are pestering me.

yes, i'm familiar with it.

yes, i've already given an opinion on the use of the nptlonly use flag.  

rather than retyping everything all over again, and re-answering questions that have already been answered for someone who's too lazy to look for the answer,  i am going to recommend that you review this thread.  :Idea: 

and while I'm at it: the support thread is located here.

</rant>

----------

## kailauro

I'm fine to be proven wrong concerning douts about what an optimized gcc can or cannot do  :Very Happy:  (page 13)

slycordinator does a little logical thinking on page 13  :Very Happy: 

of course I would't say that an optimized gcc was needed to output optimized binaries....I would instead think that willl heavily optimized gcc still be able to produce optimized binaries. For what I know, optimized gcc outputs runnable binaries and seemingly binaries that perform well, too  :Very Happy: 

I'll test this just for myself when I have the time: that on optimized gcc will output the same optimized binary than a standard gcc----to the bit... It would be fundamental fun if the results are the same  :Very Happy: 

Right now I would need to learn about using slots and stuff before having acces to a non-optimized gcc..

Compililing the kernel in just a few snappy minutes really is luxury.

A newbie like me would use md5sum + file size to start checking if the outputs are the same..even roughly.. maybe there is be a better way???

Has anyone been there-done-that allready ??

Maybe I'll get back to this business if the output is indeed different...

Just thought that a little  empirical testing would start proving  a lot about a great idea...including all the logic and symbolistics and stuff...

Once again...both my simplistic desktop and my even more simplistic server have been prepared this stage 1 from stage 3 -way and everything works fine...The questionin was more or less philosophical from the start...

--the nyyb

----------

## Sheepdogj15

oh shoot... you comment on it in the OPENING POST

my sincere apologies, Bob, newbie blonde moment  :Embarassed: 

----------

## juazp

 *Sheepdogj15 wrote:*   

>  *juazp wrote:*   worked fine for my amd64 with the arch modifications etc . thx alot =)
> 
> *well except for fb / splash , even tho it emerges fine etc it simply doesnt show up when i boot , even the res is the default sucky one* 
> 
> i had the same problem, as i mentioned earlier. yeah, other than that the stage 1 on 3tb works well on amd64.
> ...

 

ya i did compile with multilib , anyway as weird as it may seem i used the tool in gnome to set boot options and enabled some option wich i cant remember atm but it's pretty obvious one , and now has fb support etc .

I will post wich option it was later when i get home

----------

## Bob P

 *Sheepdogj15 wrote:*   

> oh shoot... you comment on it in the OPENING POST

 

directions?  we don't need no stinking directions!

----------

## nelix

I'm thinking about 2005.0...

I'm thinking this is still a nice method of install even once the 2005.0 profiles are released, because its still nice to have a working system up in say 15 minutes and then going on to optimize it while i am using it.

Its still good for new gcc builds etc with the information about what order to build your toolchain in.

and i am sure we can find other things to add, just as a general more avanced search guide.

----------

## kimchi_sg

I've changed my mind about 2005.0 being "good enough to eat off of". The final straw was a few hours ago when I needed to re-install and found out to my horror, that the 2005.0rc5 CD could not detect my motherboard's onboard NIC when I had a PCI NIC of the same type (both use the Realtek 8139too module). And since I am planning to use that box as a router, this was unacceptable.

Also, earlier before that, my daily emerge -uvDa --newuse world picked up no less than 17 packages that had been emerged during bootstrapping with the "build" or "bootstrap" USE flags, but were NOT re-emerged during emerge system without these flags.  :Evil or Very Mad: 

I'm back to 2004.3 for now. And somehow, I feel that this install method will be the superior way to install a rock solid, stable system for some time. Probably until 2006.0 comes out.  :Razz: 

----------

## nelix

btw how long before 2005.0 final is out? seems like this rebuild is taking forever  :Razz: 

----------

## kimchi_sg

 *nelix wrote:*   

> btw how long before 2005.0 final is out? seems like this rebuild is taking forever 

 

Never mind how long the devs take, unless you've got hardware problems with the 2004.3 liveCD, 2004.3 is still fighting fit.  :Very Happy: 

Tip for compiling gcc

I've gotten into the habit of compiling gcc with the "boundschecking" USE flag. This flag is good to use on non-hardened systems. It enables the HTB bounds checking patches for gcc, and at the same time skips building the hardened gcc profiles. So it saves quite a bit of time on compiling gcc, like the nptlonly flag does for glibc. And it makes gcc check for wild pointers in the source code being compiled - another Good Thing.  :Very Happy: 

If you want to enable bounds checking on your gcc when installing stage 1-on-3, insert this line at the same time as when you enable glibc's "userlocales" USE flag in package.use:

```
echo "sys-libs/glibc userlocales" >> /etc/portage/package.use

echo "sys-devel/gcc boundschecking" >> /etc/portage/package.use
```

This is to be done before the first round of compiling the toolchain!

----------

## nelix

2005.0 release would be nice for me, i have 6 systems i want to update to 2.6 headers and udev (i am aware that i can do this manualy) and 4 of those systems are the same and have issues with doscsi and are VERY out of date so i figure its much easyer to just clean install and redesign all of them.... Well thats my reasoning for wanting 2005.0.

sorry for going off topic but i just thought i would justify my self

----------

## kimchi_sg

 *nelix wrote:*   

> 2005.0 release would be nice for me, i have 6 systems i want to update to 2.6 headers and udev (i am aware that i can do this manualy) and 4 of those systems are the same and have issues with doscsi and are VERY out of date so i figure its much easyer to just clean install and redesign all of them.... Well thats my reasoning for wanting 2005.0.
> 
> sorry for going off topic but i just thought i would justify my self

 

Understood.

A goodie new in the 2005.0 liveCD: selective module loading. That should take the pain out of doscsi. Just load 1 of the modules without probing whether all the rest are needed. There's a mod=[module name] kernel parameter that does that. Nice.

Now if i can figure out how to make it recognise both my network cards at once...  :Confused: 

----------

## Bob P

my impression of 2005.0-rc5 has been less than encouraging, but for a different reason --  i have three criteria that have to be met in order for me to stop using the Stage 1/3 installation method.  failure to meet any one of the criteria is a dealbreaker.  

1.  the var/db/pkg in the 2005.0 Stage 1 tarball has to be complete.

2.  circular dependencies have to be eliminated in the base system.

3.  GCC 3.4.3 (or later) has to be marked as stable and be incorporated into the Live CD.

unfortunately, because GCC 3.4.3 is still in the testing branch, the 2005.0-rc5 Live CD has been released with GCC 3.3.4.  

for me, there is absolutely no purpose in performing a Stage 1 installation if bootstrapping will not bring in the GCC  3.4.3 toolkit.   bootstrapping with the GCC 3.4.3 toolkit would only require that i have to rebuild the entire toolkit/system and world files after bootstrapping.  this seems rather pointless, as there is no point in bootstrapping if the bootstrapped system isn't what you want it to be.  

for me, i'll continue to do the Stage 1/3 installation.

----------

## Bob P

now the second question comes along -- how to modify the Stage 1/3 method for use with 2005.0. 

for those of you who can't wait for 2005.0 and continue to ask when it will be released, PLEASE STOP!  :Exclamation:   we are not developers and we have no control over the process.  when we ask this question we get the same response that everyone else gets:  "it will be out when it is out."  so we've stopped asking, and we'd appreciate it if you would do the same.

if you're curious about whether or not this installation method is 2005.0-compliant, the answer is yes.  because 2005.0 is distributed with 2.6 kernel-compatible headers, you can omit the steps of unmerging the linux 24 headers and emerging the linux 26 headers.  beyond that, no changes appear necessary.  

 :Arrow:  please keep this in mind: 2005.0 remains experimental and has not been officially released.  this Stage 1/3 installation method remains a method of building a robust and bulletproof installation.  2005.0 as an experimental distribution compromises the integrity of this installation method.  until 2005.0 is no longer marked experimental, this guide will not be officially updated to support 2005.0.  if you choose to install 2005.0, you do so at your own risk.  please do not ask questions about it here.  this guide is for 2004.3 and 2005.0 questions will not be answered.

 :Arrow:  EDIT:  New Thread started for all 2005.0 related posts:  

https://forums.gentoo.org/viewtopic-p-2204186.html

----------

## slycordinator

I think there needs to be a simple change made to this guide. 

In section "7.1 Building the Toolkit: GCC 3.3.4."

Change

```
emerge gcc-config glibc binutils gcc
```

to 

```
emerge --nodeps gcc-config glibc binutils gcc
```

And similarly in "7.2.4 Rebuilding the System Toolkit"

Change

```
emerge glibc binutils gcc portage
```

to

```
emerge --nodeps glibc binutils gcc portage
```

This should be changed because the gcc ebuild now accepts USE="gtk" and if gtk is in your USE flags it will try to install gtk and all of it's dependencies when you try to install the most current gcc.  As it stands that will add a TON of extra pointless compile time.

----------

## kimchi_sg

 *slycordinator wrote:*   

> I think there needs to be a simple change made to this guide. 
> 
> In section "7.1 Building the Toolkit: GCC 3.3.4."
> 
> Change
> ...

 

That is the most dangerous thing I have heard you to say. What if some of the other dependencies are actually needed? For example, with --nodeps, libstdc++-v3 (which is a PDEPEND of gcc) will not get emerged, as would binutils-config.

Better include "sys-devel/gcc -gtk" in package.use instead. And possibly throw in boundschecking while we are at it. 

```
echo "sys-devel/gcc -gtk boundschecking" >> /etc/portage/package.use
```

----------

## hielvc

kimchi_sg what is also dangerous is useing "build and bootstrap" in your USE flags. For anyone not totally sure of what theyre doing or nuts like  kimchi_sg  :Wink:  they can cause big probs such as not building g++ when it builds your gcc.

----------

## kimchi_sg

 *hielvc wrote:*   

> kimchi_sg what is also dangerous is useing "build and bootstrap" in your USE flags. For anyone not totally sure of what theyre doing or nuts like  kimchi_sg  they can cause big probs such as not building g++ when it builds your gcc.

 

What makes you think I actually build my gcc with USE="build bootstrap" ?!  :Surprised: 

----------

## Sysa

 *kimchi_sg wrote:*   

>  *slycordinator wrote:*   I think there needs to be a simple change made to this guide. 
> 
> In section "7.1 Building the Toolkit: GCC 3.3.4."
> 
> Change
> ...

 

I agree with you regarding the --nodeps but maybe it worth to add --newuse instead? I think it could help if somebody does not install from scratch but fix or tune his system in accordance with the recommendations (and adjust the USE!), e.g. as me do  :Wink: . Or you think that it's ~x86 problem too?

----------

## kimchi_sg

 *Sysa wrote:*   

> I agree with you regarding the --nodeps but maybe it worth to add --newuse instead? I think it could help if somebody does not install from scratch but fix or tune his system in accordance with the recommendations (and adjust the USE!), e.g. as me do .

 

If you already have an installed system, stop looking at this topic. This topic is about building the toolchain on a fresh install of the system.

The bash wrapper script mentioned here is the more correct way to maintain the toolchain on an already installed system.  :Wink: 

----------

## Bob P

 *slycordinator wrote:*   

> I think there needs to be a simple change made to this guide. 
> 
> In section "7.1 Building the Toolkit: GCC 3.3.4."
> 
> Change
> ...

 

this is an interesting problem.  although i haven't had a chance to verify the problem, i can give a preliminary response.  i have never noticed the issue because i have never noticed gtk being emerged on the test systems.  on the test systems, the install took an entire week and i wasn't glued to the chair -- so if gtk got emerged, i could have missed it.  on my personal systems, i have gtk disabled in my use flags, which prevented the problem from occurring.

like kimchi_sg pointed out, libstdc++-v3 is not explicitly emerged but is emerged implicitly in that step.  (it gets pulled in as a dependency).  this means that if you specify --nodeps on the command line, you will prevent the emergence of libstdc++-v3.  that would not be good.

so if this is indeed a problem, then it seems that a better approach would be to disable gtk from being emerged by controlling it through the use of USE flags.  one could do this with a global USE="-gtk" type of flag, which would be appropriate during the process of installation, or one could do it with a package-specific USE flag like kimchi_sg recommended.

i have to admit, i do not yet know why gcc responds to the gtk USE flag, so it would be premature to comment on the use of a package-specific use flag in package.use if the user ultimately intends to emerge gtk.  

on the subject of saving compile time, while it certainly seems unnecessary at this point to emerge gtk, again i have to admit that i have no idea if gtk actually gets emerged -- in developing the guide, it did one heck of alot of pretend emerges of gcc, and i NEVER saw gtk being proposed, even on the systems that did not explicitly specify USE="-gtk".  if gtk does indeed emerge as a dependency of gcc in that step, can you tell me which version of gcc this behavior started with?

as another consideration, i don't think that the redundant compilations would be as extensive as you have suggested.  dependencies aren't re-compiled on the second pass if they already exist.  so if the problem does exist, at worst, gtk would be emerged once.  as it ultimately becomes part of the world file and not the system, it would also be skipped during "emerge -e system", wouldn't it?

i appreciate the heads-up on this potential problem.  until i have a chance to verify that the problem does indeed exist, it would be premature to think about altering the guide.  similarly, we have to test the solutions for reliability before we just throw them into the guide.  from a safety/reliability perspective, its better to allow some potentially unnecessary compilation than it would be to potentially break the installation method until we've found the definitive answer.

if anyone's performing a de novo installation, i'd appreciate some feedback including your obvservations until i have a chance to get a better handle on this.

----------

## Bob P

 *Sysa wrote:*   

> I agree with you regarding the --nodeps but maybe it worth to add --newuse instead? I think it could help if somebody does not install from scratch but fix or tune his system in accordance with the recommendations (and adjust the USE!), e.g. as me do . Or you think that it's ~x86 problem too?

 

i can't see any valid reason to specify "--newuse" on a de novo system installation.  :Rolling Eyes: 

----------

## kimchi_sg

 *Bob P wrote:*   

>  *slycoordinator wrote:*   This should be changed because the gcc ebuild now accepts USE="gtk" and if gtk is in your USE flags it will try to install gtk and all of it's dependencies when you try to install the most current gcc. 
> 
> this is an interesting problem.  although i haven't had a chance to verify the problem, i can give a preliminary response.  i have never noticed the issue because i have never noticed gtk being emerged on the test systems.

 

This gtk dependency hypothesis is hereby Officially Disproved.  :Razz: 

```
livecd / # USE="gtk" emerge -pv gcc-config glibc binutils gcc

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

Calculating dependencies ...done!

[ebuild     U ] sys-devel/gcc-config-1.4.0 [1.3.8-r3] 0 kB

[ebuild     U ] sys-libs/glibc-2.3.4.20050125-r1 [2.3.4.20040808-r1] -build -debug +erandom* -hardened (-multilib) +nls +nomalloccheck* +nptl* +nptlonly* +pic* +userlocales* 15,299 kB

[ebuild  N    ] sys-devel/binutils-config-1.8-r1  0 kB

[ebuild     U ] sys-devel/binutils-2.15.92.0.2-r6 [2.15.90.0.1.1-r3] -debug -multislot -multitarget +nls -test (-uclibc) 10,790 kB

[ebuild  NS   ] sys-devel/gcc-3.4.3.20050110  -bootstrap +boundschecking -build -debug -fortran -gcj +gtk -hardened (-ip28) (-multilib) -multislot (-n32) (-n64) +nls -nocxx -objc -static (-uclibc) 27,896 kB

[ebuild  N    ] sys-libs/libstdc++-v3-3.3.4  -debug +nls 22,784 kB

Total size of downloads: 76,772 kB
```

Good thing you caught me doing yet another reinstall.  :Wink: 

But it makes me wonder, why the vapier, eradicator and co would put a dummy USE flag into the gcc ebuild.  :Confused: 

EDIT: Never mind, a little sleuthing inside the toolchain eclass has turned up this nugget which is the only location where the GTK flag makes a difference:

```
gcc-compiler-configure() {

        # multilib support

        if is_multilib; then

                confgcc="${confgcc} --enable-multilib"

        else

                confgcc="${confgcc} --disable-multilib"

        fi

        # GTK+ is preferred over xlib in 3.4.x (xlib is unmaintained

        # right now). Much thanks to <csm@gnu.org> for the heads up.

        # Travis Tilley <lv@gentoo.org>  (11 Jul 2004)

        if ! is_gcj ; then

                confgcc="${confgcc} --disable-libgcj"

        elif use gtk ; then

                confgcc="${confgcc} --enable-java-awt=gtk"

        fi
```

Seems that USE="gtk" affects only the building of the AWT GUI for the gcj compiler - which won't be built unless you've turned on USE="gcj", of course. So for most people, it won't make a difference.  :Wink: 

----------

## kimchi_sg

Here's a little postscript to my previous post, since links is refusing to let me edit my previous one in its entirety.  :Evil or Very Mad: 

For those who want to splunk in the gcc ebuild, don't. They're all wafer thin in terms of length. All the meat (in other words, the specifications for what goes on during gcc compilation) is inside the toolchain eclass. That eclass probably takes the Grand Prize for efficiency in code reuse.  :Wink: 

----------

## Bob P

 *slycordinator wrote:*   

> I think there needs to be a simple change made to this guide. 
> 
> In section "7.1 Building the Toolkit: GCC 3.3.4."
> 
> Change
> ...

 

as a preliminary test of this theory, this output is obtained when USE includes no reference to "gtk" (maximize your browser window for improved readability):

```
gentoo root # emerge --newuse gcc-config glibc binutils gcc -vp

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

Calculating dependencies      ...done!

[ebuild   R   ] sys-devel/gcc-config-1.3.10-r1  0 kB

[ebuild   R   ] sys-libs/glibc-2.3.4.20050125  -build -debug -erandom -hardened (-multilib) +nls -nomalloccheck +nptl -nptlonly -pic +userlocales 0 kB

[ebuild   R   ] sys-devel/binutils-2.15.92.0.2-r1  -bootstrap -build -debug -multitarget +nls (-uclibc) 0 kB

[ebuild   R   ] sys-devel/gcc-3.4.3.20050110  -bootstrap -boundschecking -build -debug +fortran -gcj +gtk* -hardened (-ip28) (-multilib) -multislot (-n32) (-n64) +nls -nocxx -objc -static (-uclibc) 0 kB

Total size of downloads: 0 kB
```

in contrast, this is what the same command's output looks like when USE="-gtk":

```
gentoo root # emerge --newuse gcc-config glibc binutils gcc -vp

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

Calculating dependencies      ...done!

[ebuild   R   ] sys-devel/gcc-config-1.3.10-r1  0 kB

[ebuild   R   ] sys-libs/glibc-2.3.4.20050125  -build -debug -erandom -hardened (-multilib) +nls -nomalloccheck +nptl -nptlonly -pic +userlocales 0 kB

[ebuild   R   ] sys-devel/binutils-2.15.92.0.2-r1  -bootstrap -build -debug -multitarget +nls (-uclibc) 0 kB

[ebuild   R   ] sys-devel/gcc-3.4.3.20050110  -bootstrap -boundschecking -build -debug +fortran -gcj -gtk -hardened (-ip28) (-multilib) -multislot (-n32) (-n64) +nls -nocxx -objc -static (-uclibc) 0 kB
```

the difference is "+gtk*" in the first case vs. "-gtk" in the second case.  

what does the asterisk mean?  

am i missing something, or is gtk not going to be emerged when either command is executed?

EDIT: kimchi_sg beat me to the punch.   :Embarassed: 

----------

## Bob P

kimchi_sg, this is for you:

```
cd /var/db/pkg 

for p in $(grep -RiH ^KEYWORDS * | grep ~x86 | cut -d / -f -2); do echo ${p} ~x86; done >> /etc/portage/package.keywords.bob
```

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:50 am; edited 1 time in total

----------

## Bob P

well, THAT sounds like pretty good proof to me!  :Very Happy: 

----------

## kimchi_sg

I had to satisfy my curiousity so I tried this just to see if it was really GCJ that listened for the gtk USE flag.  :Razz: 

```
livecd / # USE="gcj gtk" emerge -pv glibc binutils gcc portage

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

Calculating dependencies ...done!

[ebuild   R   ] sys-libs/glibc-2.3.4.20050125-r1  -build -debug +erandom -hardened (-multilib) +nls +nomalloccheck +nptl +nptlonly +pic +userlocales 0 kB

[ebuild   R   ] sys-devel/binutils-2.15.92.0.2-r6  -debug -multislot -multitarget +nls -test (-uclibc) 0 kB

[ebuild  N    ] dev-util/pkgconfig-0.15.0  596 kB

[ebuild  N    ] media-libs/libart_lgpl-2.3.17  -debug 282 kB

[ebuild  N    ] media-libs/libpng-1.2.8  -debug 375 kB

[ebuild  N    ] media-libs/freetype-2.1.9-r1  -bindist -debug -doc +zlib 969 kB

[ebuild  N    ] x11-misc/ttmkfdir-3.0.9-r2  -debug 19 kB

[ebuild  N    ] x11-base/opengl-update-2.1.1-r1  37 kB

[ebuild  N    ] media-libs/fontconfig-2.2.3  732 kB

[ebuild  N    ] x11-base/xorg-x11-6.8.2-r1  +3dfx -3dnow +bitmap-fonts +cjk -debug -dlloader -dmx -doc -font-server -hardened -insecure-drivers -ipv6 -minimal +mmx +nls +opengl -pam -sdk +sse -static +truetype-fonts +type1-fonts (-uclibc) -xprint +xv 45,094 kB

[ebuild  N    ] app-arch/rpm2targz-9.0-r2  2 kB

[ebuild  N    ] sys-apps/utempter-0.5.5.5-r1  -debug 20 kB

[ebuild  N    ] x11-terms/xterm-200  -Xaw3d -debug -toolbar +truetype +unicode 681 kB

[ebuild  NS   ] dev-libs/glib-2.6.3  -debug -doc 2,246 kB

[ebuild  N    ] dev-libs/atk-1.9.1  -debug -doc -static 472 kB

[ebuild  N    ] media-libs/jpeg-6b-r4  -debug 598 kB

[ebuild  N    ] x11-libs/pango-1.8.1  -debug -doc -static 973 kB

[ebuild  N    ] dev-perl/XML-Parser-2.34  224 kB

[ebuild  N    ] dev-util/intltool-0.32.1  121 kB

[ebuild  N    ] dev-libs/libxml2-2.6.17  -debug -ipv6 -python +readline 2,995 kB

[ebuild  N    ] x11-misc/shared-mime-info-0.15  412 kB

[ebuild  N    ] x11-libs/gtk+-2.6.4  -debug -doc +jpeg -static -tiff 10,985 kB

[ebuild   R   ] sys-devel/gcc-3.4.3.20050110  -bootstrap -boundschecking -build -debug -fortran +gcj* +gtk* -hardened (-ip28) (-multilib) -multislot (-n32) (-n64) +nls -nocxx -objc -static (-uclibc) 0 kB

[ebuild     U ] sys-apps/portage-2.0.51.19 [2.0.51-r3] -build -debug (-selinux) 277 kB

Total size of downloads: 68,119 kB
```

Note to self: gcc seems strangely broken in the 2005.0 x86 stage 3 tarball. emerging gcc dies if boundchecking is enabled.  :Confused: 

----------

## Bob P

 *Quote:*   

> I had to satisfy my curiousity so I tried this just to see if it was really GCJ that listened for the gtk USE flag.

 

Yikes!  :Shocked: 

 *Quote:*   

> Note to self: gcc seems strangely broken in the 2005.0 x86 stage 3 tarball. emerging gcc dies if boundchecking is enabled.

 

 :Arrow:  i have also seen problems with b0rken GCC behavior in 2005.3 x86 Stage 3.  Stay away from it.

----------

## kimchi_sg

 *Bob P wrote:*   

>  *Quote:*   Note to self: gcc seems strangely broken in the 2005.0 x86 stage 3 tarball. emerging gcc dies if boundchecking is enabled. 
> 
>  i have also seen problems with b0rken GCC behavior in 2005.3 x86 Stage 3.  Stay away from it.

 

Erm... I just realised that the devil in me had made me link package.unmask to package.mask, causing the masked gcc-config 1.4.0 to be emerged and breaking the gcc emerge.  :Embarassed: 

----------

## Bob P

glad to hear that you found your error.  unfortunately, i still cannot get 2005.0 to work on my testbeds.

if we're going to continue to talk about it, i think that we should move all 2005.0 discussions out of this thread.

----------

## Bob P

 :Arrow:  New Thread started for all 2005.0 related posts:

Please post all disucssion related to Stage 1/3 on 2005.0 to the new thread.  Thanks!

https://forums.gentoo.org/viewtopic-p-2204186.html

----------

## sunldn

hi all

i am learning to install Gentoo by following Stage 1 NPTL on Stage 3 Tarball. I follow the guide on the lastest PDF file step by step.

I run emerge --sync but I got RSYNC_EXCLUDEFROM defined but file not exist from the server. 

anyone please help to solve this error please. 

Thanks all.

----------

## slycordinator

 *kimchi_sg wrote:*   

> I had to satisfy my curiousity so I tried this just to see if it was really GCJ that listened for the gtk USE flag. 
> 
> ```
> livecd / # USE="gcj gtk" emerge -pv glibc binutils gcc portage
> 
> ...

 

That explains it.  I had gcj in my USE flag.

edit:

So it seems it tries to install gtk only when BOTH gcj and gtk are in the USE flags.  Weird.

----------

## Bob P

 *sunldn wrote:*   

> i am learning to install Gentoo by following Stage 1 NPTL on Stage 3 Tarball. I follow the guide on the lastest PDF file step by step.
> 
> I run emerge --sync but I got RSYNC_EXCLUDEFROM defined but file not exist from the server. 
> 
> anyone please help to solve this error please. 

 

1.  PLEASE DO NOT CROSS-POST WITH THE SAME REQUEST IN MULTIPLE FORUMS.

2.  THIS IS NOT A SUPPORT FORUM.  SUPPORT QUESTIONS BELONG IN THE SUPPORT THREAD.

3.  YOUR QUESTION HAS ALREADY BEEN ANSWERED IN THE SUPPORT THREAD.

----------

## Viha

First, excuse me if this has been mentioned, but I really don't have the time to read through the whole thread. I'm just now using this method to reinstall after major breakage and there was a little annoyance I registered, namely the stage3 was built with ipv6 support so it somehow defaulted to using ipv6 and thus every package download would first require a loooooooong timeout before wget tries the ipv4 version of the address. Maybe this is only a problem with mirrors that actually support ipv6 like the Finnish mirror that I use. Anyway, for such cases an additional tip would be to add -ipv6 to USE and rebuilding wget before trying to emerge anything else.

----------

## kimchi_sg

 *Viha wrote:*   

> I'm just now using this method to reinstall after major breakage and there was a little annoyance I registered, namely the stage3 was built with ipv6 support so it somehow defaulted to using ipv6 and thus every package download would first require a loooooooong timeout before wget tries the ipv4 version of the address. Maybe this is only a problem with mirrors that actually support ipv6 like the Finnish mirror that I use. Anyway, for such cases an additional tip would be to add -ipv6 to USE and rebuilding wget before trying to emerge anything else.

 

Then change your download mirror.

Any package that will remain on your system after the install has to be compiled with the new toolchain to get the stability and speed promised here. Ie, any extra package (in this case, wget) you want to re-merge has to come after the second 

```
emerge glibc binutils gcc portage
```

 as well as 

```
emerge system
```

Overall, the emerge order has to be 

```
emerge gcc-config glibc binutils gcc

[CHANGE make.conf SETTINGS HERE]

emerge glibc binutils gcc portage

emerge -e system

emerge [SYSTEM TOOLS AND ANY OTHER PROGRAMS]
```

----------

## lghman

I just wanted to say that Bob P you fscking rock!  I just finished the install on my new 700m and it went off with out a hitch.  I love being able to use the -march=pentium-m in the new GCC, dont know if it really makes a differece but it makes me feel better  :Smile:  .  I also used your first set of "agressive" CFLAGS, no probs.  Excellent job!

--sonik

----------

## Viha

 *kimchi_sg wrote:*   

> blah,blah..

 emerge -e system will re emerge it, moron

----------

## Bob P

 *Viha wrote:*   

> emerge -e system will re emerge it, moron

 

in keeping with the objectives of this thread and forum, i'd like to ask kimchi_sg reconsider his decision to offer personalized help in this thread.  that's what the support thread is for. 

i'd also like to ask you resist the temptation to engage in name-calling when you don't like the answer provided by somebody that is trying to help you.  posts like that don't help anyone learn how to install gentoo, and that's what we're trying to accomplish here.

i hope that we won't waste any more time on this, and that post deletion won't become necessary.

----------

## amne

 *Viha wrote:*   

>  *kimchi_sg wrote:*   blah,blah.. emerge -e system will re emerge it, moron

 

Calling people names is considered a personal attack and results in a ban.

----------

## kimchi_sg

 *Bob P wrote:*   

> in keeping with the objectives of this thread and forum, i'd like to ask kimchi_sg reconsider his decision to offer personalized help in this thread.

 

No, I did not regard it as a support request, I saw it as a request for amendment to the tutorial proper, judging from the wording of his last sentence in that post:

 *Viha wrote:*   

> Anyway, for such cases an additional tip would be to add -ipv6 to USE and rebuilding wget before trying to emerge anything else.

 

If it was a real support request along the lines of "Help! emerge complains that RSYNC_EXCLUDES does not exist!" which we did see a couple of posts ago, I'd not have answered it here.  :Wink: 

----------

## Bob P

i was just trying to be diplomatic by collaring both of you guys.   :Idea: 

----------

## kimchi_sg

 *Bob P wrote:*   

> i was just trying to be diplomatic by collaring both of you guys.  

 

Hmm, thanks. But it was too late to prevent amne from stepping in, and something big happened as a result.  :Wink: 

----------

## Bob P

 :Arrow:  PDF UPDATE  :Arrow: 

----------

## count0nz

Great Guide Bob keep it up  :Smile: 

Another Happy Gentoo boxen useing 1 on 3

CPU0: Intel Pentium II (Klamath) stepping 04 192 meg ram

 :Smile:  266 But runs sweet  :Smile: 

Next Gentoo 1 on 3 on a P3 733 with 512Meg Ram

Then  :Smile:  1 on 3 on a Duron Applebred 1600 oc'ed to 1800 2ghz

Also 512meg ram

----------

## thebigslide

I made a script to do Bob's install unattended which can be easily built into a bootable CD to require no intervention by setting init=script and adding fdisk and mkfs commands to the head.  It requires the stage tarball in ~.  Hope someone finds this useful.

```

#!/bin/bash

##Do\ Bob\'s\ Install

echo -n  "Install on which disk: "

read instdisk

fdisk /dev/$instdisk

echo "Reboot here if you need to"

echo "Filesystem for root partition

read fstype

echo "Number of root partition

read fsnum

mkfs.${fstype} /dev/${fsnum}

mount /dev/$fsnum -t $fstype /mnt/gentoo

cd /mnt/gentoo

tar xvjpf ~/gentoo-stage3-x86-2004.3.tar.bz2

mount -t proc none /mnt/gentoo/proc

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

cp /etc/resolv.conf etc/resolv.conf

touch etc/portage/package.{use,keywords,mask,unmask}

mkdir usr/portage;chown portage:portage usr/portage

cat <<- EOF >> etc/portage/package.use

sys-libs/glibc userlocales

sys-kernel/ck-sources symlink

sys-apps/shadow pam

EOF

cat <<- EOF >> etc/portage/package.keywords

sys-devel/gcc ~x86

sys-devel/gcc-config ~x86

sys-libs/libstdc++-v3 ~x86

sys-libs/glibc ~x86

EOF

cat <<- EOF >> etc/portage/package.mask

>sys-devel/gcc-3.4.3-r1

>sys-devel/gcc-config-1.3.9

>sys-libs/libstdc++-v3-3.3.4

>sys-libs/glibc-2.3.4.20050125

EOF

rm etc/make.conf;touch etc/make.conf

cat <<- EOF >> etc/make.conf

USE="nptl gtk -pam -ipv6 mmx sse 3dnow 3dnowex -nls ssl"

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium3 -mcpu=athlon-xp -O2 -s -w -pipe -fomit-frame-pointer"

CXXFLAGS="${CFLAGS}"

PKGDIR=${PORTDIR}/packages

PORT_LOGDIR=/var/log/portage

FEATURES="autoclean userpriv usersandbox sandbox"

EOF

mkdir usr/local/portage;chown portage:portage use/local/portage

mkdir var/log/portage;chown portage:portage var/log/portage

cat <<- EOF >> etc/locales.build

en_US/ISO-8859-1

en_US.UTF-8/UTF-8

EOF

touch nptl-update;chmod +x nptl-update

cat <<- EOF >> nptl-update

#!/bin/bash

env-update && source /etc/profile

ln -sf /usr/share/zoneinfo/Canada/Central etc/localtime

emerge sync

emerge -C linux-headers && emerge linux26-headers

emerge gcc-config glibc binutils gcc --oneshot && gcc-config i686-pc-linux-gnu-3.4.3 && source /etc/profile

rm /etc/make.conf && touch /etc/make.conf

cat <<- EOTF >> etc/make.conf

USE="nptl pthreads ithreads gtk python X -pam xml xml2 zlib -ipv6 mmx ssl 3dnow 3dnowex -nls chroot sftplogging"

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium3 -O2 -s -w -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -ftracer -mtune=athlon-xp"

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

LDFLAGS="-Wl,-O1"

PKGDIR=${PORTDIR}/packages

PORT_LOGDIR=/var/log/portage

PORTDIR_OVERLAY=/usr/local/portage

PORTAGE_NICENESS=3

FEATURES="autoclean userpriv usersandbox sandbox distlocks ccache"

CCACHE_SIZE="2G"

EOTF

emerge --nodeps ccache

emerge glibc gcc binutils portage glib --oneshot && emerge -e world;env-update;source /etc/profile

EOF

chroot . /nptl-update

echo "Install a bootloader, logger, cron, kernel and reboot"

echo "The author suggests grub, syslog-ng, vixie-cron and ck-sources-2.6.10-ck6"

/bin/bash

```

EDIT:  Added --oneshot to both of the emerge statementsLast edited by thebigslide on Thu Mar 24, 2005 9:01 pm; edited 1 time in total

----------

## slycordinator

thebigslide,

Why does your script create make.conf and then later remove it and make a different copy?

----------

## thebigslide

To modify it after upgrading the gcc-3.4.3-r1

I realize I could have modified it with sed instead, but it was easier to cut and paste  :Smile: 

----------

## Bob P

nice.   :Cool:    i prefer the cut and paste method too.

i've been using partially automated installs for quite some time, but i've been too burned out to write it up for presentation.  your idea to share your script is very cool.  i thought that kimchi_sg would have been the first guy to come up with a script -- its nice to see that you beat him to the punch!

btw -- i don't think that its absolutely necessary to use "--oneshot" when emerging the toolkit components.  the stage 3 tarball already has GCC and the toolkit components in the world file.  i guess that one could argue that the newer versions of gcc are slotted, so the --oneshot is necessary, but if you use hiel and minderaser's tcupdate script, toolkit components are filtered automatically, which renders the use of --oneshot somewhat moot.

what a nice script!   :Cool:   next time i update the guide, i think i'll insert a hyperlink to your post.   :Wink: 

----------

## thebigslide

Thanks Bob!  I added the --oneshot 'just in case'.  I've gotten a lot out of this post and wanted to contribute something back.

----------

## slycordinator

 *thebigslide wrote:*   

> To modify it after upgrading the gcc-3.4.3-r1
> 
> I realize I could have modified it with sed instead, but it was easier to cut and paste 

 

Oh I didn't see that the second time through was part of the "ntpl-update" command you created.

----------

## slycordinator

thebigslide,

If you want it to be a truly unattended install, you could change it so that the filesystem type and device location are set as variables from the beginning (and not read from the console).  That way the only actual "interaction" you'd have to do is setting up those partitions with fdisk.  

And hell, if you wanted it to be REALLY automated you could use sfdisk along with a saved file containing your partition information.

----------

## thebigslide

I have been plugging away on a GTK for some time now to derive all the info needed to install, run debian's modconf to setup the kernel and automatically generate a kernel .config from the livecd's /proc/config.gz.  I like the idea of using sfdisk to setup the partition table.

----------

## slycordinator

 *thebigslide wrote:*   

> I like the idea of using sfdisk to setup the partition table.

 

Here's how you'd do it.

To store everything for your partition table:

```
dd if=/dev/(your_disk) of=mbr.save count=1 bs=512 

sfdisk -d /dev/(your_disk) > partitions.save 
```

Then to restore them:

```
dd if=mbr.save of=/dev/(your_disk) 

sfdisk /dev/(your_disk) < partitions.save 
```

The dd command saves the first 512 bytes which will get the table of primary partitions.  Then the sfdisk command saves the rest.

Of course this automated way of doing it assumes you already have a set partition table you want saved from an old configuration and the storing part must be done in a running system.

But if with each of your installs the partition scheme stays the same this is a saver.Last edited by slycordinator on Mon Mar 28, 2005 7:19 am; edited 1 time in total

----------

## Bob P

 :Rolling Eyes: 

----------

## slycordinator

Why the (  :Rolling Eyes:  ) ?  Would you have preferred this to be in the troubleshooting thread?  I was just showing a way to make his script more automated.

And I had just remembered how you'd do it so I posted it.

----------

## hielvc

thebigslide the one problem I see with your script is the  *Quote:*   

> emerge gcc-config glibc binutils gcc --oneshot && gcc-config i686-pc-linux-gnu-3.4.3 && source /etc/profile

  On my box when gcc hickuped a couple of days ago its was caused by 

```
ls /usr/lib/gcc-lib/i686-pc-linux-gnu/

3.3.3/  3.3.5/  3.4.3@  3.4.3-20050110/
```

 because gcc-config was pointing to 3.4.3 instead of 3.4.3-20050110. This is one of the re-occuring probs with updateing gcc.

----------

## Bob P

 *slycordinator wrote:*   

> Why the (  ) ?  

 

i'm just eagerly waiting for the new script to be posted.   :Wink:   its getting hard to keep holding my breath!

----------

## Bob P

 :Arrow:  Stage 1/3 Guide for 2005.0 Now Available; Experimental 

Click Here.

----------

## slycordinator

 *Bob P wrote:*   

> 
> 
> i'm just eagerly waiting for the new script to be posted.    its getting hard to keep holding my breath!

 

I've edited it to include the stuff I mentioned before:

```

#!/bin/bash

##Do\ Bob\'s\ Install

instdisk=sda

fstype=reiserfs

fsnum=sda1

# If you want to manually create partition scheme uncomment next line

#fdisk /dev/$instdisk

# If you want to use a previously saved configuration for your partition scheme

# Uncomment the next 2 lines (also change the file names to suit your saved config)

#dd if=mbr.save of=/dev/$instdisk

#sfdisk /dev/$instdisk < partitions.save

mkfs.${fstype} /dev/${fsnum}

mount /dev/$fsnum -t $fstype /mnt/gentoo

cd /mnt/gentoo

tar xvjpf ~/gentoo-stage3-x86-2004.3.tar.bz2

mount -t proc none /mnt/gentoo/proc

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

cp /etc/resolv.conf etc/resolv.conf

touch etc/portage/package.{use,keywords,mask,unmask}

mkdir usr/portage;chown portage:portage usr/portage

cat <<- EOF >> etc/portage/package.use

sys-libs/glibc userlocales

sys-kernel/ck-sources symlink

sys-apps/shadow pam

EOF

cat <<- EOF >> etc/portage/package.keywords

sys-devel/gcc ~x86

sys-devel/gcc-config ~x86

sys-libs/libstdc++-v3 ~x86

sys-libs/glibc ~x86

EOF

cat <<- EOF >> etc/portage/package.mask

>sys-devel/gcc-3.4.3-r1

>sys-devel/gcc-config-1.3.9

>sys-libs/libstdc++-v3-3.3.4

>sys-libs/glibc-2.3.4.20050125

EOF

rm etc/make.conf;touch etc/make.conf

cat <<- EOF >> etc/make.conf

USE="nptl gtk -pam -ipv6 mmx sse 3dnow 3dnowex -nls ssl"

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium3 -mcpu=athlon-xp -O2 -s -w -pipe -fomit-frame-pointer"

CXXFLAGS="\${CFLAGS}"

PKGDIR=${PORTDIR}/packages

PORT_LOGDIR=/var/log/portage

FEATURES="autoclean userpriv usersandbox sandbox"

EOF

mkdir usr/local/portage;chown portage:portage usr/local/portage

mkdir var/log/portage;chown portage:portage var/log/portage

cat <<- EOF >> etc/locales.build

en_US/ISO-8859-1

en_US.UTF-8/UTF-8

EOF

touch nptl-update;chmod +x nptl-update

cat <<- EOF >> nptl-update

#!/bin/bash

env-update && source /etc/profile

ln -sf /usr/share/zoneinfo/Canada/Central etc/localtime

emerge sync

emerge -C linux-headers && emerge linux26-headers

emerge gcc-config glibc binutils gcc --oneshot && gcc-config 2 && source /etc/profile

rm /etc/make.conf && touch /etc/make.conf

cat <<- EOTF >> etc/make.conf

USE="nptl pthreads ithreads gtk python X -pam xml xml2 zlib -ipv6 mmx ssl 3dnow 3dnowex -nls chroot sftplogging"

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium3 -O2 -s -w -pipe -fomit-frame-pointer -momit-leaf-frame-pointer -ftracer -mtune=athlon-xp"

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

LDFLAGS="-Wl,-O1"

PKGDIR=\${PORTDIR}/packages

PORT_LOGDIR=/var/log/portage

PORTDIR_OVERLAY=/usr/local/portage

PORTAGE_NICENESS=3

FEATURES="autoclean userpriv usersandbox sandbox distlocks ccache"

CCACHE_SIZE="2G"

EOTF

emerge --nodeps ccache

emerge glibc gcc binutils portage glib --oneshot && emerge -e world;env-update;source /etc/profile

EOF

chroot . /nptl-update

echo "Install a bootloader, logger, cron, kernel and reboot"

echo "The author suggests grub, syslog-ng, vixie-cron and ck-sources-2.6.10-ck6"

/bin/bash

```

I also changed the gcc-config command from gcc-config i686-pc-linux-gnu-3.4.3 to gcc-config 2. I believe that'll fix the problem hielvc noted.

edit: Fixed a typo

2nd edit: Fixed make.conf creationLast edited by slycordinator on Tue Apr 05, 2005 1:13 am; edited 1 time in total

----------

## Schietschijf

hello, first of all, I want to thank Bob for this guide! It is really wonderfull and even easier than the gentoo installation guide :p

Second, I want to tell that i did this guide but with the stage3 tarball for the amd64 2005.0. Still it's following the guide but there are only 2 differences I think.

This stage (stage3 for amd64 of the 2005.0 release) already contains gcc 3.4.x, so its al little bit shorter for amd64 users...

Second difference is that linux26-headers doesn't exist anymore in 2005.0, it's now linux-headers version 2.6.x...

That's all that was different, except from my graphical card..

Once again thank you for this guide!

[edit]

Ow, yes, also in my make.conf i did for the CFLAGS -march=athlon64 -mtune=athlon64 and all the rest stays the same...

[/edit]

----------

## Bob P

glad to hear that you've had good luck.

BTW, we have a thread specifically for using this method with 2005.0.  if anyone is interested in using this guide with 2005.0, please look there.  we're limiting this thread to 2004.3.

thanks!   :Wink: 

----------

## plonka2000

Just marking this, as I always come back to it so much...  :Wink: 

----------

## ruach

Despite my   miserable failed attempts  to get this to work with 2004.3 on Athlon-MP, I'm NOW large and in-charge on my Pentium 4 Dell C640. Thanks for the sweet tutorial Bob P!  :Very Happy: 

Maybe I'll go try that Athlon again...  :Wink: 

----------

## whabee

Great guide bob I followed it on a clean stage 3 install of 2005.0 on a P4 3.0/Intel D865GLCL and it worked flawless, was the fastest and cleanest install of gentoo I ever did and I have done about 30 to date, I love to test and break stuff. Only problems I had were typo errors on my part.  :Embarassed: 

----------

## slycordinator

I noticed a problem (that I don't know how to fix) with the script made earlier by myself and thebigslide.

Here's a section of it:

```
rm etc/make.conf;touch etc/make.conf

cat <<- EOF >> etc/make.conf

USE="nptl gtk -pam -ipv6 mmx sse 3dnow 3dnowex -nls ssl"

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium3 -mcpu=athlon-xp -O2 -s -w -pipe -fomit-frame-pointer"

CXXFLAGS="${CFLAGS}"

PKGDIR=${PORTDIR}/packages

PORT_LOGDIR=/var/log/portage

FEATURES="autoclean userpriv usersandbox sandbox"

EOF
```

After running this section of code, you get /etc/make.conf with the following:

```
USE="nptl gtk -pam -ipv6 mmx sse 3dnow 3dnowex -nls ssl"

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium3 -mcpu=athlon-xp -O2 -s -w -pipe -fomit-frame-pointer"

CXXFLAGS=""

PKGDIR=/packages

PORT_LOGDIR=/var/log/portage

FEATURES="autoclean userpriv usersandbox sandbox"
```

because when that script is run it looks at CFLAGS as a variable.  So when it sees ${CFLAGS} it evaluates that to " " since it's an undefined variable.

edit: Well the way to fix it is to explicitly set CXXFLAGS without a reference to CFLAGS if you want an automated script.

----------

## pijalu

 *slycordinator wrote:*   

> 
> 
> ...
> 
> ```
> ...

 

IMHO, escaping the $ should do the trick for CFLAG and PORTDIR

```

cat <<- EOF >> etc/make.conf

USE="nptl gtk -pam -ipv6 mmx sse 3dnow 3dnowex -nls ssl"

CHOST="i686-pc-linux-gnu"

CFLAGS="-march=pentium3 -mcpu=athlon-xp -O2 -s -w -pipe -fomit-frame-pointer"

CXXFLAGS="\${CFLAGS}"

PKGDIR=\${PORTDIR}/packages

PORT_LOGDIR=/var/log/portage

FEATURES="autoclean userpriv usersandbox sandbox"

EOF
```

----------

## slycordinator

That worked perfectly, thanks.  Editing the script as such.

----------

## Bob P

 :Arrow:  2005.0 version of the Guide is now stable and has been posted in Documentation Tips & Tricks:

https://forums.gentoo.org/viewtopic-t-319349.html

----------

