fredor,
1st - Thats what linux and open source is all about:
If you don't like sth, you change it to suit your needs : ))
2nd - I would say, what stays in the original script is rather the bare minimum than excessive. Excessive would be having to rebuild your entire system from scratch because of a broken TC. I wouldn't be leaving out linux-headers if I was doing a total rebuild. But, of course, as you like it
I'm glad that you like the script. I especially tried to make it so that one can easily adjust it to his preferences
Look out, new features coming soon _________________Portage updates your ToolChain (gcc, glibc...) in a very stupid way. Here is the solution: an emerge wrapper script

Hey, I got it right then
At least the rebuilding part
What about the order of initial updating/building?
Do you agree it should be
portage - 2x os-headers - glibc - binutils-cfg - binutils - gcc-cfg - gcc

i wonder if there's a situation where bin/gcc-config has to manually be run to switch to the new binutils/compiler? i can't remember if that's done automatically or not on major upgrades (3.3.4->3.4.3?). that would suck. _________________by design, by neglect
for a fact or just for effect

That's right - no compiling. That's why it appears only in the beginning. But I've heard reemerging it fixes weird problems with some builds and since it takes no time, I'd rather leave it as it is.

dirtyepic wrote:

i wonder if there's a situation where bin/gcc-config has to manually be run to switch to the new binutils/compiler? i can't remember if that's done automatically or not on major upgrades (3.3.4->3.4.3?). that would suck.

I was wondering about the same. There is even a TODO line in the script if you've noticed. Not sure at all but I think gcc switches to new version on minor upgrades and leaves it unchanged on major. One can't count on that though so I am thinking of adding an option to stop and ask for the profile. Wow, if things continue going the same way a tcupdate command will take 3 lines

hielvc wrote:

Depends on the day of the week sometimes, but right now gcc-config was working upto 3.4.4

What about the order of initial updating/building?
Do you agree it should be
portage - 2x os-headers - glibc - binutils-cfg - binutils - gcc-cfg - gcc

Not really. Please put binutils before glibc. The reasons for this are explained in the Linux From Scratch documentation. In fact, conventional wisdom suggests that the order should be as follows: binutils, gcc then glibc. Not only is this approach asserted by the LFS documentation, it is also asserted by the Gentoo bootstrap.sh script itself (just grep the script for "emerge").

I can think of no good reason for merging os-headers twice and the point at which portage is rebuilt (or whether it is at all) is not likely to be of any significant importance, given the intention of the script (which is to help people upgrade their toolchains on "live" systems, not build from scratch).

I would also like to point out that it is perfectly plausible to run the bootstrap script on a "live" system provided that the following line in the script is commented, so as to prevent one's configuration files from being stomped:

Code:

export CONFIG_PROTECT="-*"

With all due respect to the work that has been done here, I find myself questioning the notion that a 3rd-party "wrapper" is required. I would suggest that the use of the official bootstrap script is the sanest approach for the majority of users due to the level of quality assurance that goes into it (or put another way, the devs are usually wont to know what they are doing!). If, like me, you prefer to have a toolchain built against itself then simply run the script twice (I would be inclined to insert a "gcc-config 1" command between the two invocations if gcc is upgraded as a result of the first pass).

A tip also ... having upgraded the toolchain, if you feel the overwhelming urge to rebuild the base system packages - perhaps because of a gcc upgrade, say - then I would propose the following one-liner:

This simply has the effect of conducting the "stage 3" phase again but skipping glibc, portage, binutils, gcc and the os-headers. In actual fact, the regexes could be rendered more specific but it works fine for my particular requirements. Note that this command will not upgrade anything (current versions are maintained).

Regardless of the methodology used, if you are using a two-pass bootstrap approach then if the first pass of a bootstrap run results in gcc being upgraded, it's a good idea to set the profile by name (not number - just in case you have multiple slotted instances of gcc) and to execute source /etc/profile after switching the gcc profile. This example assumes that we were running a version of gcc lower than 3.4.3 prior to executing the first command:

Please put binutils before glibc. The reasons for this are explained in the Linux From Scratch documentation. In fact, conventional wisdom suggests that the order should be as follows: binutils, gcc then glibc. Not only is this approach asserted by the LFS documentation, it is also asserted by the Gentoo bootstrap.sh script itself (just grep the script for "emerge").

We're not bootstrapping though, nor would we want to bootstrap an already stable system. If you'll look a little further to chapter six in the LFS manual where the system is rebuilt after bootstrapping, you'll notice the new order is os-headers, glibc, binutils, gcc. This is the proper order for rebuilding the toolchain.

Quote:

I can think of no good reason for merging os-headers twice and the point at which portage is rebuilt (or whether it is at all) is not likely to be of any significant importance, given the intention of the script (which is to help people upgrade their toolchains on "live" systems, not build from scratch).

`zactly

Quote:

I would also like to point out that it is perfectly plausible to run the bootstrap script on a "live" system provided that the following line in the script is commented, so as to prevent one's configuration files from being stomped:

Code:

export CONFIG_PROTECT="-*"

With all due respect to the work that has been done here, I find myself questioning the notion that a 3rd-party "wrapper" is required. I would suggest that the use of the official bootstrap script is the sanest approach for the majority of users due to the level of quality assurance that goes into it (or put another way, the devs are usually wont to know what they are doing!). If, like me, you prefer to have a toolchain built against itself then simply run the script twice (I would be inclined to insert a "gcc-config 1" command between the two invocations if gcc is upgraded as a result of the first pass).

ack, no. bootstrapping should only be used when first installing the system, or when recovering from a critical toolchain meltdown of some kind. the idea being that as soon as you're done bootstrapping, you will be running emerge (-e) system, which will replace the bootstrapped toolkit with it's full and robust self (using an incorrect build order i might add ). bootstrapping again after that would only be making the same mistake twice. this script updates and rebuilds the toolchain properly and optimally, and has a shitload of cool features to boot._________________by design, by neglect
for a fact or just for effect

If you'll look a little further to chapter six in the LFS manual where the system is rebuilt after bootstrapping, you'll notice the new order is os-headers, glibc, binutils, gcc. This is the proper order for rebuilding the toolchain.

wow. this thread has come a long way since i last checked in on it back on page one. good work, guys!

i'd have to agree that the best order for doing the toolkit build is linux26-headers, glibc, binutils, gcc on the first pass, and then glibc, binutils, gcc, portage on the second pass. at least the way that i did it in the Stage 1/3 project. i'm glad to see that the LFS manual is in agreement. maybe i should have read it!

fwiw, i also agree that its a good idea to source /etc/profile after changing your gcc version.

ack, no. bootstrapping should only be used when first installing the system, or when recovering from a critical toolchain meltdown of some kind. the idea being that as soon as you're done bootstrapping, you will be running emerge (-e) system, which will replace the bootstrapped toolkit with it's full and robust self (using an incorrect build order i might add )

Well, the packages built by the bootstrap phase are populated in the /var/db/pkg directory so the "emerge system" command will not bother to recompile them. Obviously, it will if the -e parameter is used, but that's not standard installation procedure! That's why I use the grep magic to veto the toolchain packages themselves if I fancy rebuilding all and sundry later.

dirtyepic wrote:

bootstrapping again after that would only be making the same mistake twice. this script updates and rebuilds the toolchain properly and optimally, and has a shitload of cool features to boot.

I'm not questioning that it is a cool script But I need more convincing that the order I proposed is wrong. One thing that isn't being taken into account is that, in the LFS case, the versions that are built are consistent across the entire installation process. But in this case, we are in all likelihood dealing with version upgrades across one or more toolchain components. A concrete reason is given for binutils preceding the other packages (in the case that binutils is upgraded at least), but I have still yet to hear a concrete reason as to why that approach is wrong when the toolchain is rebuilt thereafter.

Seeing as I'm on the topic again, I'll explain how I actually do it in more detail. I go to the extent of creating a temporary chroot in order to bootstrap again, using --buildpkg to prepare binary packages. Having conducted a few tests inside the chroot to make sure nothing is obviously amiss, I install those packages "upstream" within my actual running system. That might seem excessive to some, but it's served me well - and I have no margin for error on the system that I mainly use. If I had the resources I would use a physically separate staging server for all packages that are upgraded and I know many folks do exactly that (not least, to save on downtime due to dep breakage and so forth). Mind you, the chrooted approach is something I've only adopted recently. I used to "emulate" the bootstrap process by first exporting AUTOCLEAN="no" and emerging the components in the same order as suggested by the bootstrap script, being sure to emerge clean after the binutils phase and after the entire process is complete.

Both approaches worked well for me for about 2 years worth of upgrades within one particular server's lifespan. I've used the same approach twice so far on the new server which was deployed quite recently. Having said that, I'm keeping an open mind on the matter and would very much like to know the specifics if this is in any way wrong. Could you provide more details on what the exact pitfalls might be with this build order, given the applicable scenario?

I have a quick question that is perhaps slightly OT: I'm assuming that ccache should not be used for rebuilding the TC in this way, is this correct? I was 10 minutes into re-building my TC when I thought that this might be an issue so I stopped and switched off ccache but I am unsure if this was neccessary.

I have a quick question that is perhaps slightly OT: I'm assuming that ccache should not be used for rebuilding the TC in this way, is this correct? I was 10 minutes into re-building my TC when I thought that this might be an issue so I stopped and switched off ccache but I am unsure if this was neccessary.

ccache is fine to always have on. it's pretty smart and takes into account a lot of factors such as gcc modificatiion date, a hash of the data, a difference in CFLAGS or LDFLAGS, and more. if any of these things differ with what it has cached, it doesn't use that data.

also, i just remembered - if you rebuild GCC, all your previous cache data is useless because the mod time on the GCC link is altered and therefore won't match any hash ccache has.

kerframil: you raise some good points. i'll think on this a bit, do some research and testing and get back to you. the last thing i want to be doing is giving out false information._________________by design, by neglect
for a fact or just for effect

i wonder if there's a situation where bin/gcc-config has to manually be run to switch to the new binutils/compiler? i can't remember if that's done automatically or not on major upgrades (3.3.4->3.4.3?). that would suck.

I was wondering about the same. There is even a TODO line in the script if you've noticed. Not sure at all but I think gcc switches to new version on minor upgrades and leaves it unchanged on major. One can't count on that though so I am thinking of adding an option to stop and ask for the profile. Wow, if things continue going the same way a tcupdate command will take 3 lines

i realize that i may be very late in arriving to this thread, and that you've probably already answered this question, but i'll post this anyway: when going from GCC 3.3.4 to 3.4.3, the switch of compilers is not automatic. you definitely need to perform the switch manually using gcc-config, or you're stuck with the older compiler. i used "gcc-config 2" to accomplish the switch in the Stage 1 on 3 tut.

MindEraser wrote:

hielvc wrote:

Depends on the day of the week sometimes, but right now gcc-config was working upto 3.4.4

Yeah, this is so fucked up For the last 2 weeks the gcc-3.4.3 branch is totally out of control. 20050110 swithes between -* and ~x86 every other day; -r1 breaks and gets fixed all the time too. It's so wonderful that we have this script I'm sticking to 20050110 for now.

what's the current status on gcc 3.4.3? because i've been too busy to do any toolkit updates over the past month or so, i've just kept putting them off and as a result i've managed to stay out of the rain and missed the recent problems with GCC. i had left the original 3.4.3-r1 on my stable branch boxes, and left the original 3.4.3.20050110 on my testing branch boxes, and i never ran into any of the issues that others had been mentioning. because of dumb luck i seem to have dodged the GCC-masking/unmasking bullet. at this point i'm kind of wondering if its safe to go out into the water...

now that i've had a little more time on my hands, i've finally gotten far enough down on my list of things to do that i've finally decided to test out this script. HOLY COW!!! this thing is GREAT, and i wish that i'd picked it up sooner instead of just being a lurker in this thread! i installed MindEraser's most current version, and so far i've only had the chance to perform an -uD world less toolkit and the results have been wonderful. using my preferred set of CFLAGS, everything in my world file compiled except the usual suspects -- KDE, avifile, and K3b, which don't like -fvisibility-hidden in the CXXFLAGS. much to my delight, the script even included a log of the ebuilds that failed, so that i know to change the CXXFLAG and run the script again. this is an added benefit of running the script that i had not expected, and was pleasantly surprised to see. thanks for the hard work guys, this script is definitely going to make my life easier! _________________.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks

If I only wish to update glibc and am happy with the currently running version of GCC (3.4.3.20050110) and such, would this script also be of good help? Should I bother rebuilding my toolkit if the only upgrade I wish to make is glibc?

If I only wish to update glibc and am happy with the currently running version of GCC (3.4.3.20050110) and such, would this script also be of good help? Should I bother rebuilding my toolkit if the only upgrade I wish to make is glibc?

Yeah, if any part of the toolchain needs to be updated, the whole chain should be recompiled in accordance with this script. You could also do it manually by entering the following at the command prompt:

I would like to thank hielvc and MindEraser for this awesome script, as I now have updated glibc and completely rebuilt my toolkit with it. A truly awesome script and I cannot tell how much I appreciate your work and help. Once again, thanks for making the Gentoo experience a learning experience

The emrg-wrapper.sh script is great, but I have a quick question, especially as I'm still not very up on the higher level gentoo stuff.

Today I was told by emrg-wrapper.sh that, as glibc was to be emerged, it required that I rebuild the toolchain as well.

Yes, the script is correct on this point. You should re-merge all components of the toolchain (ie, glibc, binutils, and gcc) together whenever there is an upgrade to even 1 of them._________________Murphy's Law of Gentoo installation: If a compile can fail, it will.

Listing link for those who might run into simular probs. To reiterate some advise form After upgrading glibc, libstdc++.so.5 no longer exists dont casually try to downgrade your glibc it will BREAK YOUR SYSTEM. Now you can do it but you have to un-tar a stage1 or a stage2 in your "/".root directory.. With the stage1 bootstrap it . If you used a stage2 then you and the stage1 people, after they bootstrap, need to "emerge system -eD" or use tcupdate or emrg_wrapper.sh .

Listing link for those who might run into simular probs. To reiterate a some advise form that thread, After upgrading glibc, libstdc++.so.5 no longer exists dont casually try to downgrade your glibc it will BREAK YOUR SYSTEM. Now you can do it but you have to un-tar a stage1 or a stage2 in your "/".root directory.. With the stage1 bootstrap it . If you used a stage2 then you and the stage1 people, after they bootstrap, need to "emerge system -eD" or use tcupdate or emrg_wrapper.sh .

Looks like everything is in order on my system again, though I need to configure a few things (fonts) so that they're larger.

Anyway, prior to you posting I tried to 'casually' downgrade glibc and, well, I broke my system (live and learn!).

Now, a question about the most recent version of the script. It alerted me that gcc-config needed to be emerged and it was part of the toolchain. However, when I used emrg_wrapper.sh -t, it only upgraded gcc-config and did not rebuild the toolchain. Is there something I'm missing here?

1 Mini Toolchain
2. Toolchain
3. emerge -e system less Toolchain
4 emerge -e world less System less Toolchain
5 emerge -e world less Toolchain
6. emerge -uD sytem less Toolchain
7. emerge -uD world less System less Toolchain

How do these correspond to tcupdate.sh options? Based on 0.2.2.0 I'm guessing at:

Having updated my toolchain using "tcupdate.sh -et" and hit the "libstdc++.so.5: cannot open" problem, presumably I now need to perform 3 and then 4?Nope, that seems to have been fixed by the latest version of /usr/portage/eclass/toolchain.eclass, so an "emerge --sync" followed by a toolchain re-build fixed it.