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 Previous  1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
kimchi_sg
Advocate
Advocate


Joined: 26 Nov 2004
Posts: 2915
Location: Singapore

PostPosted: Wed Aug 17, 2005 2:24 pm    Post subject: Reply with quote

Enibevoli wrote:
The man page of emerge simply reads
Code:
world contains all of the packages in system, along with any other packages listed in /var/lib/portage/world

but fails to inform what exactly is in system

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


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Wed Aug 17, 2005 8:06 pm    Post subject: Reply with quote

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

this is really an oversimplification, but it should give you an idea what the docs mean when they say:
Code:
world contains all of the packages in system, along with any other packages listed in /var/lib/portage/world

_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
linuxgeek
n00b
n00b


Joined: 02 Aug 2003
Posts: 46

PostPosted: Thu Sep 01, 2005 3:39 pm    Post subject: Reply with quote

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

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

In fact I was amazed at how stable my 2.5 Celeron system is, as in
compiling something so critical over and over and over again without
a hiccup. It is ROCK wait scratch that it is DIAMOND solid... : )

I can tell there is more responsiveness in the system now... That is what I
have seen so far...

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

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

Dare I say it! GENTOO ROCKS!!!!

Tim
_________________
Where there is a will there is a way!
Seek enlightenment!!!
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Thu Sep 01, 2005 3:42 pm    Post subject: Reply with quote

DIAMOND solid? i like that. :D
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
nautiazn85
n00b
n00b


Joined: 05 Aug 2005
Posts: 37

PostPosted: Sun Sep 04, 2005 8:24 pm    Post subject: Reply with quote

I just noticed that portage got rid of gcc3.4.4 ebuild and now has gcc3.4.4-r1. Are there any differences? If so should I recompile my whole system?
Back to top
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Mon Sep 05, 2005 3:10 am    Post subject: Reply with quote

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


Joined: 26 Nov 2004
Posts: 2915
Location: Singapore

PostPosted: Mon Sep 05, 2005 12:11 pm    Post subject: Reply with quote

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

GCC's Changelog, which you can view by going to packages.gentoo.org wrote:
*gcc-3.4.4-r1 (27 Aug 2005)

27 Aug 2005; Mike Frysinger <vapier@gentoo.org> +gcc-3.4.4-r1.ebuild:
Push out cumulative changes (especially #87631).
Back to top
View user's profile Send private message
WTFman
Apprentice
Apprentice


Joined: 04 Apr 2005
Posts: 153

PostPosted: Tue Sep 06, 2005 6:10 am    Post subject: Reply with quote

linuxgeek wrote:
Just wanted to say that.. this guide rocks...

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

In fact I was amazed at how stable my 2.5 Celeron system is, as in
compiling something so critical over and over and over again without
a hiccup. It is ROCK wait scratch that it is DIAMOND solid... : )

I can tell there is more responsiveness in the system now... That is what I
have seen so far...

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

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

Dare I say it! GENTOO ROCKS!!!!

Tim
I have a celleron processor too and it is complete crap! if it worked for you I'd be willing to bet it will work for me too! Going to try it :)
_________________
Occupation: Professional Slacker
Hobbies/Interests: Open Source Aficionado since 2005
Back to top
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Sat Oct 08, 2005 7:25 pm    Post subject: Reply with quote

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

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

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

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

A good idea? Yea/Nay?

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

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


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sat Oct 08, 2005 8:20 pm    Post subject: Reply with quote

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

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

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

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

A good idea? Yea/Nay?

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

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


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

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


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

Code:
# emerge -pv gcc gcc-config libstdc++-v3 glibc

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

Calculating dependencies ...done!
[ebuild   R   ] sys-devel/gcc-3.4.4-r1 [3.4.4] (-altivec) -bootstrap -boundschecking -build +fortran -gcj -gtk* -hardened -ip28 (-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc -static -vanilla 27,036 kB
[ebuild   R   ] sys-devel/gcc-config-1.3.12-r2  0 kB
[ebuild   R   ] sys-libs/libstdc++-v3-3.3.6  -build (-multilib) +nls +nptl 23,410 kB
[ebuild     U ] sys-libs/glibc-2.3.5-r2 [2.3.5-r1] -build -erandom -glibc-compat20 -glibc-omitfp -hardened -linuxthreads-tls (-multilib) +nls +nptl -nptlonly -pic -profile (-selinux) +userlocales 15,628 kB

Total size of downloads: 66,075 kB


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

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

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

in the big scheme of things, its a tradeoff between stability and the bleeding edge. this guide has always been about both, but the more conservatively minded users might want to use the arch version of glibc. unfortunately, when patches get applied, history has shown that the devs patch across both branches and they tend to break both testing branch and stable branch packages. in the big scheme of things, i wonder if the decision really matters...
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
ocbMaurice
Tux's lil' helper
Tux's lil' helper


Joined: 14 Feb 2003
Posts: 83
Location: Switzerland

PostPosted: Tue Oct 11, 2005 4:01 am    Post subject: speed up compilation Reply with quote

I was wondering if I could reduce the compile time and I think it's possible.
Specially the doubled emerge -e system bothered me, altough I understand why it is needed:
1) linked libraries may get removed if a newer version of that library is emerger later
2) included headers of libraries (that get compiled/updatet later) may not be compatible with the updated version
Anything else that could make a second emerge necessary?

A few people already suggested to use ccache earlier to specially speed up the second "emerge -e world". This partially has been discussed in Installing Gentoo 2004.3: Stage 1 NPTL on a Stage 3 Tarball, but there seems to be no indication wheter or not it is save to do so. One question was if ccache would notice that another compiler is used. To check that I took a look at the ccache sources. In the file ccache.c (~ line 320) I found an answer.
Code:
 /* the compiler driver size and date. This is a simple minded way
    to try and detect compiler upgrades. It is not 100% reliable */
 if (stat(args->argv[0], &st) != 0) {
   cc_log("Couldn't stat the compiler!? (argv[0]='%s')\n", args->argv[0]);
   stats_update(STATS_COMPILER);
   failed();
 }
 hash_int(st.st_size);
 hash_int(st.st_mtime);

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

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

I used this perl oneliner to avoid the inclusion of gcc-config, gcc, binutils, glibc and libstdc++-v3 in emerge -e system.
Code:
# emerge -ep system | perl -e 'while(<>) { /\]\s+([^\/]+\/.*?)\-[0-9][0-9\-\._]*.*?\s*$/ and not $1=~m/^[^\/]+\/(?:gcc\-config|gcc|binutils|glibc|libstdc\+\+-v3)$/ and $p.=$1." " } system "emerge $p"'

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

greets, Maurice
Back to top
View user's profile Send private message
DOSBoy
Tux's lil' helper
Tux's lil' helper


Joined: 26 Jun 2005
Posts: 84

PostPosted: Tue Oct 11, 2005 9:11 am    Post subject: Reply with quote

Code:

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


Says 8 hours, 42 minutes for my PII 366. Note that parts may have been built with distcc (not that much though), and it should be doubled for 2 emerge -e systems.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Wed Oct 12, 2005 6:56 pm    Post subject: Reply with quote

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

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

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

i would also point out that this Guide specifically warns the user about the time commitment that is required, and that the Guide may not be suitable for everyone. rather than emasculating the Guide by cutting parts of it out in the interest of saving time, impatient users are recommended to choose an installation method that is better suited to their needs. :idea:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Wed Oct 12, 2005 6:57 pm    Post subject: Reply with quote

KDE users may want to reconsider the use of CXXFLAGS:

http://planet.gentoo.org/developers/flameeyes/2005/10/11/that_is_not_working_man
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
WTFman
Apprentice
Apprentice


Joined: 04 Apr 2005
Posts: 153

PostPosted: Wed Oct 12, 2005 7:02 pm    Post subject: Reply with quote

Funny, KDE works fine for me, XFCE on the other hand seems buggy and unstable, could just be my hardware, but KDE works fine!
_________________
Occupation: Professional Slacker
Hobbies/Interests: Open Source Aficionado since 2005
Back to top
View user's profile Send private message
cokey
Advocate
Advocate


Joined: 23 Apr 2004
Posts: 3343

PostPosted: Fri Oct 14, 2005 2:01 am    Post subject: Reply with quote

i take it
Bob P wrote:
Copyright (c) 2005 Bob Predaina. All Rights Reserved
was a joke...
_________________
"Sex: breakfast of champions" - James Hunt
Back to top
View user's profile Send private message
odejoy
n00b
n00b


Joined: 02 Nov 2005
Posts: 8

PostPosted: Wed Nov 02, 2005 9:37 pm    Post subject: Reply with quote

n/m

Last edited by odejoy on Mon Nov 07, 2005 5:04 am; edited 1 time in total
Back to top
View user's profile Send private message
Mr. Garr
Tux's lil' helper
Tux's lil' helper


Joined: 27 Jun 2003
Posts: 130
Location: Shangri-La

PostPosted: Sat Nov 05, 2005 1:36 pm    Post subject: Reply with quote

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

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

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



is it a mistake or it realy should be like this? (the code thingy)
_________________
Illuminatus Primus
Back to top
View user's profile Send private message
Monkeh
Veteran
Veteran


Joined: 06 Aug 2005
Posts: 1656
Location: England

PostPosted: Sat Nov 05, 2005 2:16 pm    Post subject: Reply with quote

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

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

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



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


It's not a mistake.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sat Nov 05, 2005 2:25 pm    Post subject: Reply with quote

the Guide has been through 4 major revisions in the past year. i think all of the major kinks have been beaten out of it. :wink:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
scharkalvin
Guru
Guru


Joined: 31 Jan 2004
Posts: 331
Location: south florida

PostPosted: Mon Nov 14, 2005 9:10 pm    Post subject: use the 2005.0 /gcc-3.4.4 guide with 2005.1? Reply with quote

Can I follow this guide, but start out with a stage 3 tarball
from the gentoo 2005.1 install branch?


I have a K6-300 system (Asus MB with 256MB of ram).
I'd like to optimize the system around the K6 specific
march parameters. Install time isn't an issue (so long
as the power doesn't fail in the middle!) I'd like to get
an old war horse computer up doing something usefull.
I'll probably install XFCE-4 instead of Gnome or KDE, I'm
using XFCE on an old PIII and it's not a bad desktop.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Nov 14, 2005 9:20 pm    Post subject: Reply with quote

in case you missed the notices, documentation tips & tricks is not a support forum. please post support questions in the support thread. if you're not too busy to read the support thread before you post, you'll find the answer there. i'm too lazy to retype it.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
scharkalvin
Guru
Guru


Joined: 31 Jan 2004
Posts: 331
Location: south florida

PostPosted: Tue Nov 15, 2005 12:58 pm    Post subject: Reply with quote

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

\

Not at all. There are so many side threads on this one I just got lost.
You've been googled to death!
Back to top
View user's profile Send private message
eyeL
Tux's lil' helper
Tux's lil' helper


Joined: 13 Nov 2005
Posts: 82
Location: Missouri

PostPosted: Wed Nov 16, 2005 2:16 am    Post subject: Reply with quote

when it says

9.2 Building the Kernel Symlink

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


any way to make it a 2.6.14 kernel right here?
_________________
[theNPA - down for updates] | [Adopt an unanswered post]
gentoo 2005.1 [lazy] - gcc 4.1.1
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Wed Nov 16, 2005 2:25 am    Post subject: Reply with quote

sure. change what you type. :wink:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
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 Previous  1, 2, 3, 4, 5  Next
Page 4 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