Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
An emerge wrapper for breaking emerges into chunks
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4 ... 28, 29, 30  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
MindEraser
n00b
n00b


Joined: 06 Jul 2004
Posts: 26
Location: Germany

PostPosted: Thu Feb 03, 2005 12:53 am    Post subject: Reply with quote

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 8)
I'm glad that you like the script. I especially tried to make it so that one can easily adjust it to his preferences :wink:
Look out, new features coming soon :lol:
_________________
Portage updates your ToolChain (gcc, glibc...) in a very stupid way. Here is the solution: an emerge wrapper script
Back to top
View user's profile Send private message
rhill
Developer
Developer


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Thu Feb 03, 2005 1:51 am    Post subject: Reply with quote

MindEraser wrote:
Hey, I got it right then :lol:
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 :?:


hmm, no need to 2x os-headers. it's just basically 1) dl tarball 2) unpack 3) voodoo-sed-magik 4) merge. there's no compiling going on so there's not really anything to optimize.

the bin/gcc-config makes sense. i forgot about those. :D

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
Back to top
View user's profile Send private message
hielvc
Advocate
Advocate


Joined: 19 Apr 2002
Posts: 2801
Location: Oceanside, Ca

PostPosted: Thu Feb 03, 2005 3:09 am    Post subject: Reply with quote

Depends on the day of the week sometimes, but right now gcc-config was working upto 3.4.4 :wink: Off to track down " size of size_t " failures.
_________________
An A-Z Index of the Linux BASH command line
Back to top
View user's profile Send private message
MindEraser
n00b
n00b


Joined: 06 Jul 2004
Posts: 26
Location: Germany

PostPosted: Thu Feb 03, 2005 10:39 am    Post subject: Reply with quote

dirtyepic wrote:

hmm, no need to 2x os-headers. it's just basically 1) dl tarball 2) unpack 3) voodoo-sed-magik 4) merge. there's no compiling going on so there's not really anything to optimize.

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 8O
hielvc wrote:

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

Yeah, this is so fucked up :twisted: 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 :lol: I'm sticking to 20050110 for now.
_________________
Portage updates your ToolChain (gcc, glibc...) in a very stupid way. Here is the solution: an emerge wrapper script
Back to top
View user's profile Send private message
kerframil
l33t
l33t


Joined: 19 Apr 2002
Posts: 710
Location: London, UK

PostPosted: Thu Feb 10, 2005 4:30 am    Post subject: Reply with quote

MindEraser wrote:
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:
Code:
emerge -e -p system | egrep -o "[a-z][a-z][a-z]\-[^ ]*" | egrep -v "(glibc|portage|binutils|gcc|linux(26)?\-headers)" | sed -e "s/\(.*\)/=\1/" | xargs emerge --oneshot

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).
Back to top
View user's profile Send private message
kerframil
l33t
l33t


Joined: 19 Apr 2002
Posts: 710
Location: London, UK

PostPosted: Thu Feb 10, 2005 5:02 am    Post subject: Reply with quote

Just a quick clarification ...

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:
Code:
# bootstrap.sh && gcc-config i686-pc-linux-gnu-3.4.3 && source /etc/profile && bootstrap.sh
Back to top
View user's profile Send private message
rhill
Developer
Developer


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Thu Feb 10, 2005 6:39 am    Post subject: Reply with quote

kerframil wrote:
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 :wink:). 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
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 Feb 10, 2005 7:55 am    Post subject: Reply with quote

dirtyepic wrote:
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! :cool:

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! :oops:

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

keep up the good work, guys!
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
kerframil
l33t
l33t


Joined: 19 Apr 2002
Posts: 710
Location: London, UK

PostPosted: Thu Feb 10, 2005 8:20 pm    Post subject: Reply with quote

dirtyepic wrote:
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 :wink:)

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?
Back to top
View user's profile Send private message
Smoothhound
Tux's lil' helper
Tux's lil' helper


Joined: 23 Sep 2003
Posts: 149

PostPosted: Mon Feb 14, 2005 5:24 pm    Post subject: Reply with quote

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.

Thanks for all your hard work hielvc and MindEraser!
Back to top
View user's profile Send private message
rhill
Developer
Developer


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Tue Feb 15, 2005 8:18 am    Post subject: Reply with quote

Smoothhound wrote:
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
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: Sun Feb 20, 2005 7:33 pm    Post subject: Reply with quote

MindEraser wrote:
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 8O

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 :wink:

Yeah, this is so fucked up :twisted: 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 :lol: 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... :wink:

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! :D
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Satori80
Tux's lil' helper
Tux's lil' helper


Joined: 24 Feb 2004
Posts: 137

PostPosted: Thu Mar 03, 2005 11:41 am    Post subject: Reply with quote

How come glibc is part of the toolchian but glib isn't?
Back to top
View user's profile Send private message
Smoothhound
Tux's lil' helper
Tux's lil' helper


Joined: 23 Sep 2003
Posts: 149

PostPosted: Thu Mar 03, 2005 11:57 am    Post subject: Reply with quote

Satori80 wrote:
How come glibc is part of the toolchian but glib isn't?


glib is the low level core library for GTK+ and GNOME, admittedly the name is confusing.

HTH
Back to top
View user's profile Send private message
Nemein
n00b
n00b


Joined: 26 Jan 2005
Posts: 70
Location: Curitiba / BRAZIL

PostPosted: Sat Mar 05, 2005 12:55 am    Post subject: Reply with quote

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?
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 Mar 05, 2005 1:14 am    Post subject: Reply with quote

Nemein wrote:
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?

yes.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Satori80
Tux's lil' helper
Tux's lil' helper


Joined: 24 Feb 2004
Posts: 137

PostPosted: Sat Mar 05, 2005 7:37 am    Post subject: Reply with quote

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:

Code:
emerge --oneshot linux26-headers glibc && emerge --oneshot glibc binutils gcc && emerge --oneshot binutils gcc
Back to top
View user's profile Send private message
Nemein
n00b
n00b


Joined: 26 Jan 2005
Posts: 70
Location: Curitiba / BRAZIL

PostPosted: Sat Mar 05, 2005 9:37 am    Post subject: Reply with quote

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 ;)
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Wed Mar 16, 2005 12:28 pm    Post subject: Reply with quote

Hi,

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.

Was I right in using the command emrg-wrapper -t to do so?

Sorry for the silly question, just want to be sure that I know what I'm doing :).

Best,

Alex
Back to top
View user's profile Send private message
kimchi_sg
Advocate
Advocate


Joined: 26 Nov 2004
Posts: 2915
Location: Singapore

PostPosted: Wed Mar 16, 2005 1:08 pm    Post subject: Reply with quote

evoweiss wrote:
Hi,

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.

MacGillicuddy's Corollary: At the most inopportune time.

Please search and read the FAQs before posting.
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Wed Mar 16, 2005 3:28 pm    Post subject: Reply with quote

kimchi_sg wrote:

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.


Thanks, it seemed to work, but afterwards I noticed a lot of things were broken. I am running a revdep-rebuild and it suggests that packages requiring libstdc++.so.5 are broken and need to be rebuilt.

What's going on here?

Alex
Back to top
View user's profile Send private message
hielvc
Advocate
Advocate


Joined: 19 Apr 2002
Posts: 2801
Location: Oceanside, Ca

PostPosted: Thu Mar 17, 2005 4:49 am    Post subject: Reply with quote

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 :wink: .

Oh make sure you backup /etc first
_________________
An A-Z Index of the Linux BASH command line


Last edited by hielvc on Tue Mar 22, 2005 2:43 am; edited 1 time in total
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Fri Mar 18, 2005 1:06 am    Post subject: Reply with quote

Hi,

hielvc wrote:
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 :wink: .


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?

Alex
Back to top
View user's profile Send private message
lazyleopard
n00b
n00b


Joined: 06 Nov 2003
Posts: 58

PostPosted: Sat Mar 19, 2005 7:58 am    Post subject: Reply with quote

hielvc wrote:
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:

1. tcupdate.sh -t
2. tcupdate.sh -et
3. tcupdate.sh -ew system
4. tcupdate.sh --exclude=system -ew world
5. tcupdate.sh -ew
6. tcupdate.sh -w system
7. tcupdate.sh --exclude=system -w world

Am I anywhere near correct?

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.
Back to top
View user's profile Send private message
Maedhros
Bodhisattva
Bodhisattva


Joined: 14 Apr 2004
Posts: 5511
Location: Durham, UK

PostPosted: Sat Mar 19, 2005 6:51 pm    Post subject: Reply with quote

Moved from Portage & Programming.
_________________
No-one's more important than the earthworm.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3, 4 ... 28, 29, 30  Next
Page 3 of 30

 
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