Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Stage 1/3 Installation Guide for 2005.0 and GCC 3.4.4
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Sat Jun 04, 2005 6:37 pm    Post subject: Stage 1/3 Installation Guide for 2005.0 and GCC 3.4.4 Reply with quote

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

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

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

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

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

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




Faster than a Speeding Bullet...

More Powerful than a Locomotive!



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

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


Background

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

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

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

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

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


Objective

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

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

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

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


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


1. Download and Burn the Minimal Installation CD. The .ISO image required for the hardware used in this example is
Code:
http://gentoo.osuosl.org/releases/x86/2005.0/installcd/install-x86-minimal-2005.0.iso


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


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

Code:
# 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:

Code:
 # 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:

Code:
# 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:

Code:
# 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:

Code:
# 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:

Code:
# 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.

Code:
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.

Code:
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.

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

Code:
# 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:

Code:
# mkswap /dev/hda2 && swapon /dev/hda2


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

Code:
# 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:

Code:
# cd /mnt/gentoo


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

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

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

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


If you need to check the list of Gentoo Mirrors, Click Here.
(If your architecture is not x86 you will need to change the path and filename to suit your needs.)


5.2 Verify the md5sum of the Tarballs.

Code:
# md5sum -c stage3-x86-2005.0.tar.bz2.md5
stage3-x86-2005.0.tar.bz2: OK


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

Code:
tar -xjpvf stage3-x86-2005.0.tar.bz2


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


5.4 Installing Portage

5.4.1 Download a Fresh Portage Snapshot from the Internet.

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

5.4.2 Extract the Portage Snapshot

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

Code:
# wget http://gentoo.osuosl.org/snapshots/portage-20050326.tar.bz2
# wget http://gentoo.osuosl.org/snapshots/portage-20050326.tar.bz2.md5sum
# md5sum -c portage-20050326.tar.bz2.md5sum
# tar -xjvf /mnt/gentoo/portage-20050326.tar.bz2 -C /mnt/gentoo/usr

Some of these steps will take a while to complete.



6. Installing the Gentoo Base System

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

Code:
# 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.

Code:
# mount -t proc none /mnt/gentoo/proc
# mount -o bind /dev /mnt/gentoo/dev
# cp /proc/mounts /mnt/gentoo/etc/mtab



6.3 Chroot into the New Environment

Code:
# chroot /mnt/gentoo /bin/bash
# env-update
# source /etc/profile



6.4 Set the Date and Time

6.4.1 Set the Correct Date and Time.

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

Code:
# date 032719302005
Sun Mar 27 19:30:00 Local time zone must be set--see zic manual page 2005


6.4.2 Set the Time Zone Symlink.

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

Code:
# 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:

Code:
# rm /etc/localtime
# ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime
Sun Mar 27 19:32:50 CST 2005


6.4.3 Get it Right for Daylight Savings Time.

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

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


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

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

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

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

Code:
# cat /etc/make.conf

CHOST="i586-pc-linux-gnu"
CFLAGS="-O2 -march=pentium -fomit-frame-pointer -pipe"
CXXFLAGS=${CFLAGS}
ACCEPT_KEYWORDS="x86"
PORTAGE_TMPDIR=/var/tmp
PORTDIR=/usr/portage
DISTDIR=${PORTDIR}/distfiles
PKGDIR=${PORTDIR}/packages
PORT_LOGDIR=/var/log/portage
PORTDIR_OVERLAY=/usr/local/portage
GENTOO_MIRRORS="<your mirror goes here> http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
RSYNC_RETRIES="3"
RSYNC_TIMEOUT=180
MAKEOPTS="-j2"
PORTAGE_NICENESS=3
AUTOCLEAN="yes"
FEATURES="ccache distlocks sandbox userpriv usersandbox"
CCACHE_SIZE="512M"
RSYNC_EXCLUDEFROM=/etc/portage/rsync_excludes
USE="nptl"



6.6 Additional Portage Configuration

6.6.1 Create Portage Directories

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

Code:
# mkdir /var/log/portage
# mkdir /usr/local/portage


6.6.2 Package Keywords - Enabling GCC 3.4.4 in the Stable Branch

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

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

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

Code:
# cat /etc/portage/package.keywords

~sys-devel/gcc-3.4.4 ~x86
sys-devel/gcc-config ~x86
sys-libs/libstdc++-v3 ~x86
sys-libs/glibc ~x86
sys-devel/binutils ~x86
sys-libs/timezone-data ~x86


6.6.3 Update the Portage Tree

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

Code:
emerge --sync



6.7 Activate User Locales

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

6.7.1 Activate the userlocales USE flag for glibc

Code:
# cat /etc/portage/package.use

sys-libs/glibc userlocales
sys-devel/libperl ithreads
dev-lang/perl ithreads


6.7.2 Specify the user locales to build.

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

Code:
# cat /etc/locales.build

en_US/ISO-8859-1
en_US.UTF-8/UTF-8


7. Building the Toolkit

7.1 Building the Toolkit: GCC 3.3.5

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

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


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



7.2 Re-Building the Toolkit: GCC 3.4.4

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

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


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.

Code:
CFLAGS="-O3 -march=pentium -fforce-addr -fomit-frame-pointer -ftracer -pipe"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"


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

Code:
CFLAGS="-O2 -march=pentium -fomit-frame-pointer -pipe"
CXXFLAGS=${CFLAGS}


7.2.2 Configuring the Default C Compiler

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

Code:
# gcc-config -l
1] i686-pc-linux-gnu-3.3.5.20050130-r1
[2] i686-pc-linux-gnu-3.3.5.20050130-r1-hardened
[3] i686-pc-linux-gnu-3.3.5.20050130-r1-hardenednopie
[4] i686-pc-linux-gnu-3.3.5.20050130-r1-hardenednopiessp
[5] i686-pc-linux-gnu-3.3.5.20050130-r1-hardenednossp
[6] i686-pc-linux-gnu-3.4.4 *
[7] i686-pc-linux-gnu-3.4.4-hardened
[8] i686-pc-linux-gnu-3.4.4-hardenednopie
[9] i686-pc-linux-gnu-3.4.4-hardenednopiessp
[10] i686-pc-linux-gnu-3.4.4-hardenednossp


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

Code:
# gcc-config 6


7.2.3 Updating the System Environment

An additional command updates our system environment:

Code:
# env-update && source /etc/profile


7.2.4 Rebuilding the System Toolkit

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

Code:
# emerge glibc binutils libstdc++-v3 gcc portage


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

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

Code:
# emerge -e system && emerge -e system


7.2.5 Prune the GCC Compiler

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

Code:
# gcc-config -l
# emerge -P gcc


7.2.6 Summary

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

Step 1:
Code:
# env-update && source /etc/profile && emerge gcc-config glibc binutils libstdc++-v3 gcc

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

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




8.0 Building the World

8.1 Emerge Ccache (Optional)

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

Code:
# emerge ccache


8.2 Emerging Programs

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

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

# emerge --nodeps acpid ntp


8.3 Updating the Environment

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

Code:
# 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:

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

Code:
# 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.

Code:
# emerge gentoo-sources


9.2 Building the Kernel Symlink

Code:
# rm /usr/src/linux
# cd /usr/src
# ln -s linux-2.6.12-gentoo-r6 linux


9.3 Configuration

9.3.1 Enable udev Support

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

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

Code:
# 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:

Code:
# 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:

Code:
# 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:

Code:
# (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.

Code:
# echo boatanchor > /etc/hostname

or
Code:
# cat /etc/conf.d/hostname
HOSTNAME="boatanchor"


10.2.2 Set Your Domainname


Code:
# echo mydomain.com > /etc/dnsdomainname
# echo nis.mydomain.com > /etc/nisdomainname

or
Code:
# 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.

Code:
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.

Code:
127.0.0.1        localhost.localdomain       localhost
192.168.0.5      boatanchor.mydomain.com     boatanchor


10.2.4 Add domainname to the Default Runlevel

Code:
# 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:

Code:
# emerge splashutils splash-themes-gentoo
# splash_geninitramfs -v -g /boot/fbsplash-emergence-1024x768 -r 1024x768 emergence && splash_geninitramfs -v -g /boot/fbsplash-emergence-1280x1024 -r 1280x1024 emergence && splash_geninitramfs -v -g /boot/fbsplash-emergence-1600x1200 -r 1600x1200 emergence && rc-update add splash default


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


10.4 Grub Bootloader

10.4.1 Grub.conf

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

Code:
# 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.

Code:
# Grub boot menu configuration file
#
# Boot automatically after 30 secs.
timeout 30

# By default, boot the second entry.
default 1

# Fallback to the first entry.
fallback 0

# Use default Grub Splash image
# splashimage=(hd0,0)/grub/splash.xpm.gz
#
# Use custom (downloaded) Gentoo Splash Image
splashimage=(hd0,0)/grub/gentoo.xpm.gz

# Boot Gentoo Linux (no framebuffer)
title Gentoo-2.6.12-r6 
root (hd0,0)
kernel (hd0,0)/vmlinuz ro root=/dev/hda3 video=vesafb:ywrap,pmipal,1024x768-16@85

# Boot Gentoo Linux at 1024x768 framebuffer resolution
title Gentoo-2.6.12-r6, 1024x768
root (hd0,0)
kernel (hd0,0)/vmlinuz ro root=/dev/hda3 video=vesafb:ywrap,pmipal,1024x768-24@85 splash=verbose,fadein,theme:emergence CONSOLE=/dev/tty1
initrd (hd0,0)/fbsplash-emergence-1024x768

# Boot Gentoo Linux at 1280x1024 framebuffer resolution
title Gentoo-2.6.12-r6, 1280x1024
root (hd0,0)
kernel (hd0,0)/vmlinuz ro root=/dev/hda3 video=vesafb:ywrap,pmipal,1280x1024-24@85 splash=verbose,fadein,theme:emergence CONSOLE=/dev/tty1
initrd (hd0,0)/fbsplash-emergence-1280x1024

# For installing GRUB into the hard disk
title Install GRUB into the hard disk
root (hd0,0)
setup (hd0)



10.4.2 Installing Grub onto the Hard Disk

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

Code:
# 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.

Code:
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.


Code:
# <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:

Code:
# 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.

Code:
# 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:

Code:
# 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:

Code:
# 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:

Code:
# 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.

Code:
# 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.

Code:
# 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:

Code:
# 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.


Code:
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!

Code:
# shutdown -r now

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

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

boatanchor login:




12. TROUBLESHOOTING


If you encounter problems after rebooting, consider the following:

:arrow: kernel configuration errors are the most common cause of failure on first boot.
:arrow: grub configuration errors are another common cause of failure on first boot.
:arrow: if you have device problems, read the Gentoo udev Guide.

Have fun with your new Gentoo system!


13. If You Need Help

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

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

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

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



14. Another Essential Tool: Emerge Wrapper for System Updates

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


15. Corrections, Errors, Omissions

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



16. Downloadable PDF Now Available

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

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



17. Support my Documentation Writing Efforts

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



18. REVISION HISTORY

2005-06-05: corrected typos.
2005-06-15: added hyperlink to Support Thread.
2005-08-14: updated Introduction to clarify the resolution of the /var/db/pkg issue in 2005.0.
2005-08-15: updated for Gentoo-Sources 2.6.12 idiosyncracies and new grub.conf kernel commands
2005-08-22: updated gcc-config 6
2005-11-05: updated package.keywords to reflect nightmorph's old recommendations re: glibc-2.3.5-r3 and timezone-data.

Google Sucks.

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

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

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

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

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

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


Last edited by Bob P on Sat Feb 18, 2006 3:32 pm; edited 16 times in total
Back to top
View user's profile Send private message
amne
Bodhisattva
Bodhisattva


Joined: 17 Nov 2002
Posts: 6378
Location: Graz / EU

PostPosted: Sat Jun 04, 2005 7:20 pm    Post subject: Reply with quote

Moved from Installing Gentoo to Documentation, Tips & Tricks. I assume in here is a better place for this.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Sat Jun 04, 2005 7:30 pm    Post subject: Reply with quote

i'm okay with that if that's the way you'd like it. i had thought that since this was an experimental method, it should be posted elsewhere, as the Guides that get posted in the Documentation Tips & Tricks forum are expected to work! :P
Back to top
View user's profile Send private message
Ansur
Tux's lil' helper
Tux's lil' helper


Joined: 08 Jul 2004
Posts: 84
Location: Ireland

PostPosted: Sat Jun 04, 2005 7:34 pm    Post subject: Reply with quote

I was about to install Gentoo on my laptop so I'll follow this guide, hopefully everything works out fine ;)
_________________
Real programmers don't document. If it was hard to write, it should be hard to understand.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Sat Jun 04, 2005 7:55 pm    Post subject: Reply with quote

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

Code:
# gcc-config -l
/usr/bin/gcc-config: line 1: /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110: No such file or directory
 * /usr/bin/gcc-config: Profile does not exist or invalid setting for /etc/env.d/gcc/i686-pc-linux-gnu-3.4.3-20050110
[1] i686-pc-linux-gnu-3.4.4
[2] i686-pc-linux-gnu-3.4.4-hardened
[3] i686-pc-linux-gnu-3.4.4-hardenednopie
[4] i686-pc-linux-gnu-3.4.4-hardenednopiessp
[5] i686-pc-linux-gnu-3.4.4-hardenednossp


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

Code:
gentoo pentium # gcc-config 1
 * Switching to i686-pc-linux-gnu-3.4.4 compiler...
/usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
 * /usr/bin/gcc-config: Could not get portage CHOST!
/usr/bin/gcc-config: line 1: env: command not found
 * /usr/bin/gcc-config: Could not get portage CHOST!
/usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
 * /usr/bin/gcc-config: Could not get portage CHOST!
/usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
 * /usr/bin/gcc-config: Could not get portage CHOST!
/usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
 * /usr/bin/gcc-config: Could not get portage CHOST!                                                                                                  [ ok ]

 * If you intend to use the gcc from the new profile in an already
 * running shell, please remember to do:

 *   # source /etc/profile



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

Code:
gentoo pentium # ls -lh /usr/lib/gcc/i686-pc-linux-gnu/3.4.4
total 5.3M
-rw-r--r--  1 root root 1.7K Jun  4 14:03 crtbegin.o
-rw-r--r--  1 root root 2.2K Jun  4 14:03 crtbeginS.o
-rw-r--r--  1 root root 2.0K Jun  4 14:03 crtbeginT.o
-rw-r--r--  1 root root 1.3K Jun  4 14:03 crtend.o
-rw-r--r--  1 root root 1.5K Jun  4 14:03 crtendS.o
-rw-r--r--  1 root root 4.5K Jun  4 14:03 hardened.specs
-rw-r--r--  1 root root 4.5K Jun  4 14:03 hardenednopie.specs
-rw-r--r--  1 root root 4.5K Jun  4 14:03 hardenednopiessp.specs
-rw-r--r--  1 root root 4.5K Jun  4 14:03 hardenednossp.specs
drwxr-xr-x  4 root root  536 Jun  4 14:03 include
drwxr-xr-x  3 root root  136 Jun  4 14:03 install-tools
-rw-r--r--  1 root root 1.2K Jun  4 14:03 libfrtbegin.a
-rw-r--r--  1 root root 349K Jun  4 14:03 libg2c.a
-rwxr-xr-x  1 root root  754 Jun  4 14:03 libg2c.la
lrwxrwxrwx  1 root root   15 Jun  4 14:03 libg2c.so -> libg2c.so.0.0.0
lrwxrwxrwx  1 root root   15 Jun  4 14:03 libg2c.so.0 -> libg2c.so.0.0.0
-rwxr-xr-x  1 root root 160K Jun  4 14:03 libg2c.so.0.0.0
-rw-r--r--  1 root root 259K Jun  4 14:03 libgcc.a
-rw-r--r--  1 root root  94K Jun  4 14:03 libgcc_eh.a
lrwxrwxrwx  1 root root   13 Jun  4 14:03 libgcc_s.so -> libgcc_s.so.1
-rw-r--r--  1 root root  35K Jun  4 14:03 libgcc_s.so.1
-rw-r--r--  1 root root  37K Jun  4 14:03 libgcov.a
-rw-r--r--  1 root root 1.7M Jun  4 14:03 libstdc++.a
-rwxr-xr-x  1 root root  909 Jun  4 14:03 libstdc++.la
lrwxrwxrwx  1 root root   18 Jun  4 14:03 libstdc++.so -> libstdc++.so.6.0.3
lrwxrwxrwx  1 root root   18 Jun  4 14:03 libstdc++.so.6 -> libstdc++.so.6.0.3
-rwxr-xr-x  1 root root 812K Jun  4 14:03 libstdc++.so.6.0.3
-rw-r--r--  1 root root 1.8M Jun  4 14:03 libstdc++_pic.a
-rw-r--r--  1 root root 149K Jun  4 14:03 libsupc++.a
-rwxr-xr-x  1 root root  849 Jun  4 14:03 libsupc++.la
-rw-r--r--  1 root root 4.5K Jun  4 14:03 specs
-rw-r--r--  1 root root 4.5K Jun  4 14:03 vanilla.specs


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

Code:
# cat /etc/ld.so.conf

# ld.so.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
/usr/local/lib
/usr/lib/opengl/xorg-x11/lib
/usr/i686-pc-linux-gnu/lib
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110
/usr/lib/MozillaFirefox
/usr/lib
/usr/qt/3/lib
/usr/kde/3.3/lib
/usr/lib/libstdc++-v3/


to this:

Code:
gentoo pentium # cat /etc/ld.so.conf
# ld.so.conf autogenerated by env-update; make all changes to
# contents of /etc/env.d directory
/usr/local/lib
/usr/lib/opengl/xorg-x11/lib
/usr/i686-pc-linux-gnu/lib
#/usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4
/usr/lib/MozillaFirefox
/usr/lib
/usr/qt/3/lib
/usr/kde/3.3/lib
/usr/lib/libstdc++-v3/


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

i honestly don't know if you'll run into these problems when performing the Stage 1/3 Install with GCC 3.4.4, but i've posted it for your guys just in case...
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Sat Jun 04, 2005 9:03 pm    Post subject: Reply with quote

GCC 3.4.4 install failure related to libstdc++.so.6 reported to bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=95062
Back to top
View user's profile Send private message
rutski89
Guru
Guru


Joined: 14 Mar 2005
Posts: 468
Location: United States N.Y.

PostPosted: Sat Jun 04, 2005 9:19 pm    Post subject: Reply with quote

Code:
# cat /etc/portage/package.keywords

~sys-devel/gcc-3.4.4 ~x86
sys-devel/gcc-config ~x86
sys-libs/libstdc++-v3 ~x86
sys-libs/glibc ~x86
~sys-devel/gcc-3.4.4 ~x86 Are you sure thats right? A '~' in the front with a version number attached? I've persoanlly never seen either, what do they do?
_________________
<< ^ | ~ >>
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Sat Jun 04, 2005 9:29 pm    Post subject: Reply with quote

rutski89 wrote:
Code:
# cat /etc/portage/package.keywords

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


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

the atom specifically enables the testing branch version of GCC while restricting the testing branch version number to 3.4.4. it may be helpful to review the rules on atoms that are used for package masking if the syntax of the command seems unfamiliar. :idea:
Back to top
View user's profile Send private message
rutski89
Guru
Guru


Joined: 14 Mar 2005
Posts: 468
Location: United States N.Y.

PostPosted: Sat Jun 04, 2005 9:41 pm    Post subject: Reply with quote

Great, that makes sense :D It un-maskes 3.4.4 and 3.4.4 only. Where are these atom rules? I remeber a while back seeing some basic stuff in the "how to work with portage" documentation, but they were never this detalied. Also, I under stand what it does, however, isn't specifing the version number enough for this? What does the '~' mean :oops: ? Feel Free to put a link to an faq/doc as your answer if you know one 8O
_________________
<< ^ | ~ >>
Back to top
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Sun Jun 05, 2005 12:59 am    Post subject: Reply with quote

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


Joined: 14 Mar 2005
Posts: 468
Location: United States N.Y.

PostPosted: Sun Jun 05, 2005 1:11 am    Post subject: Reply with quote

nightmorph wrote:
the ~ in front of the package means that any revision of gcc 3.4.4 can be used; whenever the ebuild for gcc 3.4.4-r1, or 3.4.4.20050610-r3, or 3.4.4-r78 comes out, gcc 3.4.4 will be upgraded to this latest version. It still locks in the base package series of gcc 3.4.4, while allowing any suffixes to be added to this. So 3.4.4.20050610 is allowed, but NOT 3.4.5, for example.
Wonderful, thats exactly the answer I was looking for. I'm sure the BoB P didn't answer because its busy testing this guide 8)
_________________
<< ^ | ~ >>
Back to top
View user's profile Send private message
Clyde
n00b
n00b


Joined: 06 Jan 2005
Posts: 15
Location: Greenville, SC

PostPosted: Sun Jun 05, 2005 2:52 am    Post subject: minor correction Reply with quote

I think sections 7.2.5 and 7.2.6 are accidentally reversed. Also, the 7.2.5 summary one-liners are missing the libstdc++-v3 from sections 7.1 and 7.2.4.
Back to top
View user's profile Send private message
Ansur
Tux's lil' helper
Tux's lil' helper


Joined: 08 Jul 2004
Posts: 84
Location: Ireland

PostPosted: Sun Jun 05, 2005 11:21 am    Post subject: Reply with quote

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

Would that mean that when the installation is finished, you add the use-flags you want and start compiling whatever you want, or should you then perform
Code:
emerge -e system
again?
_________________
Real programmers don't document. If it was hard to write, it should be hard to understand.
Back to top
View user's profile Send private message
Naveg
n00b
n00b


Joined: 20 May 2005
Posts: 73

PostPosted: Sun Jun 05, 2005 2:38 pm    Post subject: Reply with quote

does this guide fix the dreaded libstdc++ errors?
Back to top
View user's profile Send private message
Ansur
Tux's lil' helper
Tux's lil' helper


Joined: 08 Jul 2004
Posts: 84
Location: Ireland

PostPosted: Sun Jun 05, 2005 3:10 pm    Post subject: Reply with quote

There were no problems here, at least, though this is only a single case :)
_________________
Real programmers don't document. If it was hard to write, it should be hard to understand.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Sun Jun 05, 2005 5:00 pm    Post subject: Reply with quote

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

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

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

in contrast. with the tilde atom enabled for GCC 3.4.3, portage will NOT use GCC 3.4.3.20050125, even though portage's atom rules suggest that it should. :(
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Sun Jun 05, 2005 5:09 pm    Post subject: Re: minor correction Reply with quote

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

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

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

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

thanks for the feedback.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Sun Jun 05, 2005 5:22 pm    Post subject: Reply with quote

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

Would that mean that when the installation is finished, you add the use-flags you want and start compiling whatever you want, or should you then perform
Code:
emerge -e system
again?

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

:arrow: Gentoo Fundamental: if there's a question about whether you need to perform a recompile after updating your USE flags, then do an emerge --newuse --pretend. :idea:
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Sun Jun 05, 2005 5:37 pm    Post subject: Reply with quote

:arrow: Official Support Thread for 2005.0 & GCC 3.4.4 -- click here.
Back to top
View user's profile Send private message
Clyde
n00b
n00b


Joined: 06 Jan 2005
Posts: 15
Location: Greenville, SC

PostPosted: Sun Jun 05, 2005 10:59 pm    Post subject: Reply with quote

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

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

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

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


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

If the goal is to use testing branch toolchain components, but prevent accidental toolchain updates, would it make sense to use = instead of ~ ?
Back to top
View user's profile Send private message
mudrii
l33t
l33t


Joined: 26 Jun 2003
Posts: 789
Location: Singapore

PostPosted: Mon Jun 06, 2005 9:13 am    Post subject: Reply with quote

-fomit-frame-pointer is default in gcc 3.4.4 and do not need to insert in make.conf
From GCC manual 3.4.4
Code:
-fomit-frame-pointer
    Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on some machines.

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

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

_________________
www.gentoo.ro
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Mon Jun 06, 2005 4:48 pm    Post subject: Reply with quote

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

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

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

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


Last edited by Bob P on Mon Jun 06, 2005 5:27 pm; edited 1 time in total
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Mon Jun 06, 2005 5:23 pm    Post subject: Reply with quote

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

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

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

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

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


Joined: 15 Oct 2004
Posts: 41

PostPosted: Mon Jun 06, 2005 5:55 pm    Post subject: Re: minor correction Reply with quote

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

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

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

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

thanks for the feedback.


Well i must be a real Jackass, cause i tried to do a Stage 1/3 gcc 3.4.4 over the weekend and only got a chance to see this thread today when i was back at work.
I based my method on your 3.4.3 version, and did not have any problems with pruning gcc right after the first build of gcc 3.4.4 with the 3.3.5 version.
What problems was this meant to cause, why are you not meant to prune gcc 3.3.5 til after emerge -e system if you are no longer compiling anything else with 3.3.5 ?
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3374
Location: USA

PostPosted: Mon Jun 06, 2005 6:08 pm    Post subject: Reply with quote

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

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

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

this is a pretty good example of why the Stage 1/3 Installation Method is only recommended for experts.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page 1, 2, 3, 4, 5  Next
Page 1 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum