Rebuilding the System Toolkit

[SAngeli]

Hi,

when re-building the System Toolkit (stage 1 after bootstrap finishes), I run # emerge glibc binutils gcc portage. Among this list, do I have to compile gcc-config too or not?

Is there anything else missing or is it fine?

Thank you,
Spiro

[moocha]

Don't emerge those packages by themselves. First run gcc-config to select the compiler specs you want, source /etc/profile., then run

[SAngeli]

this is what I have been doing so far:

1) Bootstrap the system for the first time
# cd /usr/portage
# scripts/bootstrap.sh
2) Verify my Default C Compiler
# gcc-config -l
If gcc is set to an older version change the default gcc compiler to the latest version number.
3) Apply final settings to /etc/make.conf
4) Rebuilding the System Toolkit
# emerge glibc
# emerge binutils
# emerge gcc
# emerge portage
5) Building the System
# emerge --emptytree system

Now, as you can see re-compiling the toolkit comes before building the system.

What is wrong in this sequence?
If the sequence is correct, in which precise step I would emerge if needed gcc-config?

[bosyotech]

[SAngeli]

Hi bosyotech,

I like your location description I live there too!

As for your advices, I agree for all of them.
I just wish to make a clarification:

If I rebuild my toolkit just after bootstrapping, then whatever comes after the re-compilation is with the new system toolkit. If this is so far correct, then you would emerge e- system only once. Try to see it from this sequence:
1) bootstrap
2) final make.conf changes
3) re-build toolkit
(notice, so far I never did emerge -s system)
4) I now have a new complete system toolkit
5) emerge e- system
6) later or emerge -uD world (or something like this)

Would you agree that following the above sequence there is no space for a second emerge -e system? Perhaps, there must be something missing in my thinking if I am wrong. If so, please let me know using a sequence like mine to illustrate your point. This will help me understand.

Thank you,
Spiro

[moocha]

I've made very clear over the last one and a half years the reasons for which I consider the two emerge -e system procedure necessary: leftover header files coupled with wrongful inclusion via #include <> instead of include "", leftover static libraries, buggy toolkit ebuilds that miss dependencies that are internally picked up by the configure scripts.
Do whatever you want. I warned you. But don't come crying back to me.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin

[SAngeli]

Hi

I believe you missunderstood my questions.

As am learning this important portion of toolkit, I have to ask questions perhaps even silly as long as I get it.

So, now that you have explained to me the reason for performing emerge -e system twince, could you please do me a favor so that I will not ask any further:

Could you put in SEQUENCE the steps to undertake? Please start from before bootstrap and end before emerge gentoo-sources. Make sure to state all package names you emerge throughout the sequence.

This will solve all questions and will make me understand.

I thank you for your patience,
Spiro

[moocha]

1. Untar stage 1.
2. emerge --sync
3. Bootstrap.
4. Doublecheck the compiler via gcc-config -l, set it to one of the options, and source /etc/profile.
5. Then

   Code:

   emerge -e system emerge -e system

But I highly recommend you don't use stage 1. Use stage 1 only if you really, really need to change the CHOST. If you don't need to change the CHOST, install from stage 3 like this:

1. Untar stage 3.
2. emerge --sync
3. Doublecheck the compiler via gcc-config -l, set it to one of the options, and source /etc/profile.
4. Then

   Code:

   emerge -e system emerge -e system

It's faster, more reliable, and just as "optimized".
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin

[SAngeli]

Hi moocha,

thank you. Much better for me to see it in this way.
Step 1 - 4 (through Stage 1) is OK.
In between step 4 and 5 I was always doing this:

- Apply final settings to /etc/make.conf
- Rebuilding the System Toolkit
# emerge glibc
# emerge binutils
# emerge gcc
# emerge portage

Then continue with as you say:
emerge -e system
emerge -e system

Could you tell me if the above steps for rebuilding the toolkit are wrong, right, unnecessary?
Thank you,
Spiro

[moocha]

I can copypaste my above post again if you want... It's obviously unnecessary since you would be compiling those packages FOUR TIMES if you emerged them separately too.
If you choose stage 1 you will need to have them compiled three times (the first time in the bootstrap).
Stage 3 will only require you to compile them two times. That's one of the reasons I recommend it.
Changing the USE flags should be done before the two emerge -e system. Changing the USE flags is tricky on stage 1 since you can easily end up with a weird setup.
Do what you want, since you're obviously either not reading what I'm writing, or are just trolling.

Edit: *sigh* I could've been less harsh, but still... There is more than one way to ask for advice .
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin

[SAngeli]

Hi,

Please don't say Do what you want, since you're obviously either not reading what I'm writing, or are just trolling.

I am not playing here nor wasting your time. I am trying to understand and if i make mistakes or what is obvious might not be to me its part of my asking.

I only now realize that when you perform emerge -e system, glibc, binutils, gcc, portage are compiled too.
And therefore, it is wrong to emerge them separately and before emerge -e system and then again through -e system.
Correct?

I believe I understand now clearly your explanations and believe do not have furhter questions. I apologize it took me few extra lines to understand and thank you for your time and patience.

If I might have something else it is not clear to me I will post back.

For now, thank you and have a great day,
Spiro

[moocha]

[SAngeli]

Hi and thank you for your reply.

thank you more because you took the initiative of explaining again the Stage choice principle.
It is something I believed I understood but am glad you went over.

Now, you say: Only use stage 1 when you need to change the CHOST.

Could you please give me an example of when a user would change CHOST from Stage 1 to Stage 3? I never had any opportunity nor any example for this case. This will make me understand, through an example, its use.

My other question after I read your answer. I first wish to focus on Stage 1 validity.

Thank you,
Spiro

[moocha]

[SAngeli]

Hi moocha,

for sure I am gratefull to your time and commitment in letting me learn, the proper way.
Yes, I now understand your earlier frustration.

Now, hands on your explanations. I will ask questions based on it. Anytime I make mistakes please point it out and correct it for me.

Bob P. says: Anything other than a Stage 3 tarball suffer from circular dependencies within the base system, and they have the potential to leave behind unwanted files from the stage tarball because /var/db/pkg is incomplete.
By just being aware of this makes me prefer Stage 3 as my first choice. But, let's continue.

When I need to burn my LiveCD, based on my CPU I select either (for this example) x86 family or AMD64.
Under x86 I then have several other CPUs. Under AMD64 instead no.
Immediately, I could say that for AMD64 it makes no sense to use stage 1 because CHOST will never change. Correct?
But, for x86 I could say the same. Even if x86 has x86, pentium4, pentium3, i686, athlon-xp if I do my homework properly I should choose immediately the correct tarball that matches my CPU. If this is also correct, I should not use Stage 1 but instead I should use Stage 3. Correct?

So, in both cases, if I pick right the first time I do not find any place for Stage 1. Correct?
So, this should solve my issue.

For curiosity and further understanding: If I always choose the right tarball for the proper CPU, when is that I will use Stage 1 changing CHOST settings? Could you please give me an example of a PC that would need Stage 1?

Now, Second Part: (I hope to pass the test)

I try to summarize the important steps. (I cross my fingers)
1. I download and untar stage3-x86-2005.0.tar.bz2
2. .........
3. Chroot into the New Environment
4. I configure /etc/make.conf putting all the settings and for USE flags putting only "nptl"
5. Here I do two things at once Install/Update the Portage Tree
( instead of installing Portage before chrooting and then update it, could I skipp installing it before chrooting and just with emerge --sync install it now at this stage? I do not see why doing it twice, unless I miss some important concepts)
How am I doing so far untill here? Any correction?

Now the difficult part.
You adivced me, above in one of your replies, to do:
6. # Doublecheck the compiler via gcc-config -l, set it to one of the options, and source /etc/profile.
# Then

[moocha]

[SAngeli]

[EDITED]: After reflecting on what I have learned, I removed questions I found my answers.

Cool!

I believe I passed the exam, right?

Now, to make sure:
1) Please repeet your answer for this:
( instead of installing Portage (tar -xvjf /mnt/gentoo/portage-<date>.tar.bz2 -C /mnt/gentoo/usr) before chrooting and then update it (with emerge --sync), could I skipp installing it before chrooting but just performing emerge --sync at the step where instead I shoud just update it (because it is implied that it was already installed it)? I have done it several times and did not have any problem. I ask this because I see here doing two things at once: install and update. Rather, I can just install the updated version. Could it be that I might be wrong and that this could not be proper way?

Could you please confirm me these steps:

a. PC with Gentoo installed, kde installed and all application installed. When I make some important changes to my make.conf use flags, I must adapt my Entire System to New USE Flags. Correct?
This is how I do it:
1. emerge --depclean
2. revdep-rebuild
Is this complete or is there something missing (maybe like emerge -e system world)?

b. I also know that still, when my entire Gentoo system is completed, with KDE installed as well as all applications, when I upgrade C compiler, I must do this:
1. download/install my new compiler
(is it emerge gcc or which applcation that would trigger them all by the dependency?)
2. set the new version gcc-config <number which refers to the latest version>
2. env-update
3. source /etc/profile
4 emerge gcc-conifg glibc binutils gcc portage
Again, is this complete or is there something missing (maybe like emerge -e system world must be done after)?

c. Bob P. does emerge glibg binutils gcc portage by itself prior to emerge -e system (twice)? As I understand Bob P. states that by doing so he will rebuild only the new compiling toolkit so that the compiling toolkit, compiled with the proper order (agains what portage might be ordering it with, can then compile the system. So, the strenghts here is the order of compilation for re-building the compiling toolkit. I like this and wish to implement it just before emerge -e system twice. Could I do so, in your openion or is it a waste of time? Please let me know.

Lastly, I have one PC (Pentium Celeron) that untill two days ago I completed succesfully instllation of Gentoo through Stage 1. I paused at after emerge -e system. Would it be wise to install gentoo again from stage 3 or for this case I could continue, knowing about what stage 1 creates? Obviously I need to perform emerge -e system twice, if so. Note, that I do not mind wiping out gentoo and start again with stage 3, but wish an experienced openion.

Thank you for the help.

Spiro