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

[Bob P]

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

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

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

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



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

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

[hielvc]

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

[deXtuX]

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

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

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

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

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

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

[Bob P]

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

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

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

[Bob P]

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

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

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

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

[hielvc]

Your right. I ig a vattren. I thought of petitioning the Muderators to become a honorary l33t since I kant spill or type and in 1 post I managed to look like I was stutttttttering.
Now lets see 1-6-05 minus 4-19-02 is ..........Hummm Im not near as prolific you or Kimcihi_sg. You know ya shouldnt take speed, but then I shouldnt take downers

[deXtuX]

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

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

[Hobbit_HK]

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

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

[Bob P]

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

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

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

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

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

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

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

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

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

[Bob P]

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

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

[Hobbit_HK]

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

Nope, I did:

Code: Select all

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

And after editing make.conf I did:

Code: Select all

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

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

That seems like a very good idea...

[hielvc]

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

Code: Select all

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

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

[Bob P]

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

Code: Select all

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

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

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

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

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

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

[thecookie]

Hi!

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

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

Code: Select all

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

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

Code: Select all

livecd / # env-update && source /etc/profile && emerge -C linux-headers && emerge linux26-headers && emerge gcc-config glibc binutils gcc
>>> Regenerating /etc/ld.so.cache...
 * Caching service dependencies...

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

>>> unmerge: No packages selected for removal.

Calculating dependencies ...done!
>>> emerge (1 of 1) sys-kernel/linux26-headers-2.6.8.1-r2 to /

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

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

6.6.2 Update the Portage Tree

Update our portage snapshot to include the current portage tree.

Code: Select all

emerge --sync

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

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

Thanks.

[seringen]

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

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

Thanks.

Code: Select all

mkdir /user/local/portage

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

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

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

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

[thecookie]

Code: Select all

mkdir /user/local/portage

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

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

[Bob P]

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

Code: Select all

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

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

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

Code: Select all

livecd / # env-update && source /etc/profile && emerge -C linux-headers && emerge linux26-headers && emerge gcc-config glibc binutils gcc
>>> Regenerating /etc/ld.so.cache...
 * Caching service dependencies...

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

>>> unmerge: No packages selected for removal.

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

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

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

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

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

6.6.2 Update the Portage Tree

Update our portage snapshot to include the current portage tree.

Code: Select all

emerge --sync

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

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

Code: Select all

# mkdir /usr/local/portage

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

[Bob P]

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

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

[hielvc]

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

Code: Select all

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

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

Code: Select all

 emerge  world -uDp

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

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

emerge system -ep

Calculating system dependencies ...done!
[ebuild N ] sys-devel/patch-2.5.9-r1
[ebuild N ] sys-devel/gnuconfig-20040214
[ebuild N ] sys-libs/ncurses-5.4-r5
[ebuild N ] app-shells/bash-3.0-r7
[ebuild N ] sys-devel/binutils-config-1.6
[ebuild N ] sys-apps/sed-4.1.2
[ebuild N ] sys-libs/zlib-1.2.2
[ebuild N ] dev-python/python-fchksum-1.7.1
[ebuild N ] sys-libs/readline-5.0-r1
[ebuild N ] sys-devel/flex-2.5.4a-r5
[ebuild N ] sys-apps/debianutils-1.16.7-r4
[ebuild N ] sys-apps/portage-2.0.51-r8

.......... second page midway down
[ebuild N ] sys-devel/binutils-2.15.92.0.2-r2
[ebuild N ] sys-apps/cronbase-0.3.1
[ebuild N ] sys-apps/man-1.5o_p2
[ebuild N ] sys-devel/bison-1.875d
[ebuild N ] sys-devel/gcc-3.4.3-r1
[ebuild N ] sys-libs/libstdc++-v3-3.3.4
[ebuild N ] sys-kernel/linux26-headers-2.6.8.1-r2
[ebuild N ] sys-apps/sysvinit-2.86
[ebuild N ] sys-apps/baselayout-1.11.8
[ebuild N ] sys-libs/glibc-2.3.4.20041102
[ebuild N ] app-arch/bzip2-1.0.2-r4
..........

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

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

Code: Select all

emerge world -uDp>wrld.lst
grep -i liunx26 wrld.lst 
grep -i glibc wrld.lst

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

emerge linux26-headers glibc && emerge glibc binutils gcc && emerge binutils gcc 
   
---to clean your file ----
cut -f2 -d "]" -s wrld.lst |cut -f1 -d "[">wrld1.lst

   ----edit out linux-headers, glibc, binutils,gcc----
nano wrld.lst

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

Code: Select all

for emerge sysrem/world -e

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

-----no need to test as -e rebuilds everything including your toolchain ---
-----remove linux26-headers, glibc,binutils, gcc-------------
nano wrld.lst     

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

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

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

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

[hielvc]

I also ran

Code: Select all

 emerge linu26-headers glibc && glibc binutils gcc

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

Code: Select all

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

would probably be the correct form.

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

[Bob P]

I also ran

Code: Select all

 emerge linux26-headers glibc && glibc binutils gcc

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

Code: Select all

 emerge linux26-headers glibc && emerge glibc binutils gcc

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

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

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

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

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

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

[Bob P]

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

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

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

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

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

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

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

[hielvc]

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

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

[caravela]

the CXXFLAG -fvisibility=hidden makes several packages fail to compile or linking.
fam,openslp,some kde pacakges (arts ,kdelibs,...)

[kimchi_sg]

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

USE THESE CFLAGS AT YOUR OWN RISK

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

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

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

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

Error: C compiler cannot create executables!

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

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

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

removed

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

removed

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

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