Stage 1/3 Installation Support - 2005.0/2005.1 & GCC 3.4.4

Message

Bob P · Post by **Bob P** » Sun Jun 05, 2005 5:36 pm

Stage 1/3 Installation -- 2005.0/2005.1 & GCC 3.4.4 -- Official Support Thread

This is the Offical Support Thread for the Stage 1/3 Installation Method for Gentoo 2005.0 & GCC 3.4.4. Please post all of your support requests to this thread.

NOTE: The Stage 1/3 Guide is an ADVANCED installation method. Support is offered for questions that uniquely pertain to the Stage 1/3 installation method. Support is NOT offered for Gentoo Fundamentals questions. New Users with general questions about Gentoo are advised to RTM or to seek help in the other threads in the Gentoo Forums.

How To Ask For Support

When asking for support, please give us all of the information that we need to approach your problem. This would include:

1. the full output of the error message you received
2. the output of "emerge --info"
3. the name of the tarball that you installed from

Please Note

To efficiently utilize the time that I spend providing support, I will only respond to support requests that are posted to this thread, so that the answers will remain available as reference material for anyone who may need to refer to them. I will no longer repond to ANY Personal Messages or e-mails requesting support. All Personal Messages sent to me that contain personalized support requests will be deleted without a reply.

Please post ALL support requests in the Stage 1/3 Support Thread, where everyone can benefit from the answer!

Thanks, and have fun!

How To Update After a Stage 1/3 Install

Download the Toolkit Update Scripts by hielvc and minderaser http://forums.gentoo.org/viewtopic-t-31 ... t-481.html

Quick Reference: Common Errors Associated with Stage 1/3 Installs

Emerge --sync: A New Version of Portage is Available http://forums.gentoo.org/viewtopic-t-34 ... t-155.html

Security Violation: A file exists that is not in the manifest http://forums.gentoo.org/viewtopic-t-325007.html

Framebuffer Problems with 2.6.12 Kernels http://forums.gentoo.org/viewtopic-t-34 ... rt-40.html

Problems Setting Hostname & Domainname http://forums.gentoo.org/viewtopic-t-34 ... rt-35.html

"emerge -e system" fails at python-fchksum http://forums.gentoo.org/viewtopic-t-31 ... t-401.html

C Compiler Cannot Create Executables: http://forums.gentoo.org/viewtopic-t-294109.html

Glibc Will Not Compile: http://forums.gentoo.org/viewtopic-t-31 ... rt-42.html

Failure on First Boot: http://forums.gentoo.org/viewtopic-t-29 ... rt-31.html

Gensplash and Bootsplash Problems: http://forums.gentoo.org/viewtopic-t-29 ... rt-19.html

Genkernel - Unsupported: http://forums.gentoo.org/viewtopic-t-29 ... t-176.html

Reiser 4 - Unsupported: http://forums.gentoo.org/viewtopic-t-29 ... rt-51.html

AMD64 - Unsupported: http://forums.gentoo.org/viewtopic-t-31 ... t-427.html

Off-Topic: Common Problems NOT Related to the Stage 1/3 Installation Method

Gentoo Fundamentals. Basic questions about Gentoo are not appropriate for this thread. New Users with questions are advised to RTM and are invited to read Installing Gentoo and Portage & Programming.

Grub Errors. Grub errors are not germane to the Stage 1/3 Guide. If you need help in learning how to install the boot loader, read the sticky Grub Error Collection thread. Every possible Grub configuration problem has already been addressed in that thread.

Emerge Command Syntax. If you've never installed Gentoo before, or if you just don't know the syntax of the "emerge" command, then you need to review the Gentoo Fundamentals and the man page for the emerge command. If you still have problems after doing that, I would seek help in the Support Forums such as Installing Gentoo and Portage & Programming.

Bob P · Post by **Bob P** » Sun Jun 05, 2005 5:42 pm

-outdated information removed-

Gentoonie · Post by **Gentoonie** » Mon Jun 06, 2005 2:25 pm

For people that are running a jackass system and want to upgrade their gcc 3.4.3 to gcc 3.4.4 and _dont_ want to run into the dreaded libstdc++.so.6 problem, heres a simple solution:

For some reason, on emerging gcc.3.4.4, portage removes the complete tree of gcc 3.4.3 during runtime to update it with 3.4.4, so theres no libstdc++.so.6 left. Unfortunately this one is needed for further emerges and even gcc-config requires this file. Do a

Code: Select all

USE="multislot" emerge gcc

and you wont run into that weird problems because gcc 3.4.4 is installed to another slot. You can then safely switch to gcc 3.4.4 and later unmerge 3.4.3 if you wish to do so.

Greetings

Clyde · Post by **Clyde** » Mon Jun 06, 2005 3:38 pm

Ignorant of the multislot option, I accomplished what I hope is the same result--I guess (?). I temporarily set AUTOCLEAN=no in make.conf just long enough to emerge gcc 3.4.4 and set it as default with gcc-config before a subsequent toolchain rebuild (using hielvc's emwrap) removed it. No errors since....

I also modified the package.keywords gcc line to "~sys-devel/gcc-3.4.4 ~x86", but now I'm considering changing that ~ to an =, and similarly locking down other toolchain components, to prevent any accidental updates....

Bob P · Post by **Bob P** » Mon Jun 06, 2005 5:37 pm

Gentoonie wrote:
Code: Select all
USE="multislot" emerge gcc

thanks for the tip. after we talked about this yesterday, i could have sworn that i had posted the multislot solution, but i guess that i got wrapped-up doing other things and forgot about it. thanks.

IIRC, an equivalent (and persistent) method of doing this could be accomplished by changing the contents of package.keywords to include the following:

Code: Select all

~sys-devel/gcc-3.4.4 ~x86 multislot

Bob P · Post by **Bob P** » Mon Jun 06, 2005 5:39 pm

yep -- i did post it -- in the Jackass! Support Group.

http://forums.gentoo.org/viewtopic-t-33 ... t-199.html

for a minute there, i thought that my memory was failing!

Gentoonie · Post by **Gentoonie** » Mon Jun 06, 2005 5:47 pm

Bob P wrote:yep -- i did post it -- in the Jackass! Support Group.

http://forums.gentoo.org/viewtopic-t-33 ... t-199.html

for a minute there, i thought that my memory was failing!

Ah i didnt notice that one. I browsed through several of the stage1/3 topics but didnt notice that one. Just wanted to be sure

Bob P · Post by **Bob P** » Mon Jun 06, 2005 6:07 pm

yeah, i know what you mean. sometimes i feel like i'm tracking too many threads.

starrbuck · Post by **starrbuck** » Tue Jun 07, 2005 3:49 pm

Hi Bob,

I'm using Jackass 2005.0 from the Athlon XP tar file. My system upgraded itself to GCC 3.4.4 and did NOT encounter the missing libstdc++.so.6 issue. Wonder why it worked with no interference on my part?

Do I need to rebuild the toolkit or do anything else now that 3.4.4 is installed?

Code: Select all

# emerge --info
Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.11-gentoo-r9 i686)
=================================================================
System uname: 2.6.11-gentoo-r9 i686 AMD Athlon(tm) XP 2000+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.5 [2.3.5 (#1, May  9 2005, 20:43:40)]
ccache version 2.3 [enabled]
dev-lang/python:     2.3.5
sys-apps/sandbox:    [Not Present]
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.16
virtual/os-headers:  2.6.8.1-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-march=athlon-xp -mtune=athlon-xp -pipe -O3 -fweb -frename-registers -fforce-addr
-momit-leaf-frame-pointer -fomit-frame-pointer -ftracer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb
/usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-xp -mtune=athlon-xp -pipe -O3 -fweb -frename-registers -fforce-addr
-momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -fvisibility-inlines-hidden"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo http://gentoo.osuosl.org
http://www.ibiblio.org/pub/Linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="x86 3dnow X apache2 apm avi berkdb bitmap-fonts cdr crypt cups curl dba dvd dvdr
eds emboss encode esd exif fam foomaticdb fortran ftp gd gdbm gif gnome gpm gstreamer
gtk gtk2 hal howl imagemagick imlib innodb java jikes jpeg junit libg++ libwww mad mikmod
mmx motif mozilla mp3 mpeg mysql ncurses nls nptl ogg oggvorbis opengl oss pam pdflib perl
php png python quicktime readline sdl slang spell ssl svga tcpd tiff truetype
truetype-fonts type1-fonts userlocales voodoo3 vorbis xml xml2 xmms xv zlib userland_GNU
kernel_linux elibc_glibc"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

Bob P · Post by **Bob P** » Tue Jun 07, 2005 4:08 pm

starrbuck wrote:Hi Bob,

I'm using Jackass 2005.0 from the Athlon XP tar file. My system upgraded itself to GCC 3.4.4 and did NOT encounter the missing libstdc++.so.6 issue. Wonder why it worked with no interference on my part?

reading the bug threads, it looks like @dsd squashed the GCC 3.4.4 libstdc++.so.6 bug over the weekend, but there are still some other bugs that need to be fixed.

Do I need to rebuild the toolkit or do anything else now that 3.4.4 is installed?

when i upgraded to GCC 3.4.4, i rebuilt my entire toolkit using the methods described in the stage 1/3 install. realistically speaking, if you've made a major upgrade to a toolkit component, and you want to apply the upgrade to your entire system, you need to do this:

Code: Select all

emerge -e system
emerge -e system
emerge -e world
emerge -e world

alternatively, you could use the minderaser / hielvc update scripts to rebuild the toolkit and then the world files.

Bob P · Post by **Bob P** » Tue Jun 07, 2005 5:29 pm

starrbuck wrote:Hi Bob,

I'm using Jackass 2005.0 from the Athlon XP tar file. My system upgraded itself to GCC 3.4.4 and did NOT encounter the missing libstdc++.so.6 issue. Wonder why it worked with no interference on my part?

your system upgraded itself???

please tell me you're not doing emerge -uD world in a cron job.

starrbuck · Post by **starrbuck** » Tue Jun 07, 2005 7:17 pm

Bob P wrote:your system upgraded itself??? please tell me you're not doing emerge -uD world in a cron job.

I knew you couldn't resist picking up on and commenting on that, so I left it there for a trap.

No, I'm not doing any emerges in cron jobs. In fact, when I saw 3.4.4 was to be installed, I said no and did some reading in the forum. Most of the comments I saw led me to believe that there were just minor bug fixes and that there was little or no danger in upgrading. However, my confidence has waned since reading your more recent messages, so I'm just trying to figure out the best way to go forward from here.

Bob P · Post by **Bob P** » Tue Jun 07, 2005 8:40 pm

the problem that alot of people fail to realize is that the possibility for human error is introduced with every revision and/or upgrade.

i hate to say it, but i have to come to expect that the minor bugfix revisions/upgrades to the toolkit typically do more harm than good -- during the first few days of their life cycle they completely b0rk everyone's system, just like GCC 3.4.4 has done this week. it takes a good week of troubleshooting to weed-out the truly stupid mistakes that very smart people often make. then, once the simple oversights are fixed, the bugfixes actually do what they're supposed to do.

anyone that's gullible enough to put a testing branch update into their cron job is just asking to have their box turned into a bug magnet.

IMO, the best thing to do is not to fall sucker for a version upgrade as soon as it comes out. let some other guy who's obsessed about having the most-up-to-date system on his block be the guy who's updating every day and reporting all of the bugs.

and don't upgrade unless the bugfixes in the update actually solve a problem that you've encountered. in other words -- if it ain't broke, don't fix it.

starrbuck · Post by **starrbuck** » Tue Jun 07, 2005 9:16 pm

I agree!

What would have been the best way to make it not have upgraded to GCC 3.4.4? Put something specific in the /etc/portage/package.keywords file to make it stay at 3.4.3?

96140 · Post by **96140** » Tue Jun 07, 2005 10:07 pm

You need to modify the atom in front of the necessary packages in package.keywords; use an = in front of the appropriate toolchain packages to lock them down. Then you will not be upgraded to gcc 3.4.4. So you'd end up with =whatever-category/gcc-3.4.3-r3 ~x86 in package.keywords. It would be a good idea to apply the same atom to binutils and the other toolchain packages, as they all support one another. I'm not sure that upgrading the other toolkit components while not upgrading gcc is the best idea.

cynric · Post by **cynric** » Tue Jun 07, 2005 10:51 pm

First off, nice howto, Bob P. In regards to the last two posts, would it also be aesthetically appropriate to put ">whatever-category/gcc-3.4.3" in package.mask?

jmbsvicetto · Post by **jmbsvicetto** » Wed Jun 08, 2005 12:35 am

cynric wrote:First off, nice howto, Bob P. In regards to the last two posts, would it also be aesthetically appropriate to put ">whatever-category/gcc-3.4.3" in package.mask?

Are you sure that you didn't meant "<whatever-category/gcc-3.4.4"? Both are acceptable, but I think that you want to limit gcc to any version before 3.4.4, instead of forcing to have any version after 3.4.3

cynric · Post by **cynric** » Wed Jun 08, 2005 1:05 am

Er, yes. A simple, but grosse error on my part.

Bob P · Post by **Bob P** » Wed Jun 08, 2005 7:06 am

nightmorph wrote:You need to modify the atom in front of the necessary packages in package.keywords; use an = in front of the appropriate toolchain packages to lock them down. Then you will not be upgraded to gcc 3.4.4. So you'd end up with =whatever-category/gcc-3.4.3-r3 ~x86 in package.keywords. It would be a good idea to apply the same atom to binutils and the other toolchain packages, as they all support one another. I'm not sure that upgrading the other toolkit components while not upgrading gcc is the best idea.

that's one way to do it, but that's not the way that i chose to do it. i don't like using the "=" operator, as that sticks you with one individual revision. i prefer the tilde operator that allows you to specify a revision and its updates.

one thing that you guys really need to remember is that its foolish economy to try to over-wrangle the configuration of package.keywords to prevent system updates. imho, the only reason to mess with the package keywords stuff is to define what packages you want when you build your system. that involves a minimal amount of editing, as the only packages that you really need to specify during a build are typically GCC and maybe glibc.

in contrast, package masking is NOT a good way to regulate upgrades. the best way to avoid unwanted upgrades is actually quite simple -- do not perform emerges with the "-u" parameter!

the scripts by hielvc and minderaser are much more efficient ways to approach the problem. my opinion is that people get carried away with package masking. my experience is that package masking is the hard way to accomplish the same goal.

Bob P · Post by **Bob P** » Wed Jun 08, 2005 7:07 am

starrbuck wrote:I agree!

What would have been the best way to make it not have upgraded to GCC 3.4.4? Put something specific in the /etc/portage/package.keywords file to make it stay at 3.4.3?

if you look at the Stage 1/3 Guide for GCC 3.4.3, the package.keywords statement answers your question.

starrbuck · Post by **starrbuck** » Wed Jun 08, 2005 5:14 pm

Bob P wrote:if you look at the Stage 1/3 Guide for GCC 3.4.3, the package.keywords statement answers your question.

Yes, but Jackass! only has it without the additional restrictions:

Code: Select all

sys-devel/gcc ~x86

...so this is why I got the 3.4.4 upgrade.

All this talk about bugs in 3.4.4 has me concerned. Should I back out 3.4.4 and to back to 3.4.3? What's the best and safest way to do that?

starrbuck · Post by **starrbuck** » Fri Jun 10, 2005 12:29 am

Never mind. I put this in my package.keywords:

Code: Select all

~sys-devel/gcc-3.4.3.20050110 ~x86

...then I ran 'emerge gcc' and it put 3.4.3 back in. I'm staying at this level until I see reason to upgrade.

96140 · Post by **96140** » Fri Jun 10, 2005 12:41 am

Good show. That's the better way to do it. My suggestion was only for users who absolutely did not want an upgrade of gcc past what they had, even ignoring -r# revisions. I, too, have no reason to upgrade to 3.4.4; there seem to be too many problems with it; so much for it being a supposed "bug fix" release!

I might consider it worth upgrading once more reports trickle in about if it affects the efficient running of a system once all world packages are recompiled with it. If there are significant performance gains to be had, then maybe I'll update. For now, it's a bit too bleeding edge, especially if my computer ends up doing the bleeding!

But kudos to your particular package.keywords; that allows for more controlled upgrading without moving up to 3.4.4.

Bob P · Post by **Bob P** » Fri Jun 10, 2005 5:21 pm

starrbuck wrote:Never mind. I put this in my package.keywords:
Code: Select all
~sys-devel/gcc-3.4.3.20050110 ~x86
...then I ran 'emerge gcc' and it put 3.4.3 back in. I'm staying at this level until I see reason to upgrade.

Good Show. That's exactly what I meant when I said, "if you look at the Stage 1/3 Guide for GCC 3.4.3, the package.keywords statement answers your question."

Bob P · Post by **Bob P** » Fri Jun 10, 2005 5:23 pm

just to make the previous comments clear: this is what you need to do to put GCC 3.4.3 back:

Code: Select all

# cat /etc/portage/package.keywords

# for a 586 CHOST
~sys-devel/gcc-3.4.3.20050110 ~x86
sys-devel/gcc-config ~x86
sys-libs/libstdc++-v3 ~x86
~sys-libs/glibc-2.3.4.20050125 ~x86

Code: Select all

# cat /etc/portage/package.keywords

# for a 686 CHOST:
~sys-devel/gcc-3.4.3.20050110 ~x86
sys-devel/gcc-config ~x86
sys-libs/libstdc++-v3 ~x86
sys-libs/glibc ~x86