I do have the lastest stable version of gcc-config, and while I realize that a lot of people run unstable systems (I have several unstable packages, as well, but none of them part of the core system), it obviously should work with all stable packages, as well.

curmudgeon I updated the gcc-conf.sh script on the prior page and the sample output with me as user running it. It should pickup and use /etc/env.d/gcc/config or /etc/env.d/gcc/config-"${CHOST}". You can either copy paste or download it from the link. If you would run it and post back whether it works or not.

Whaoo curmudgeon your saying that changing " config-"${CHOST}" " to just "config" fixs your problem StifflerStealth your having the same prob? If so could you both post your " emerge --info " ? Thanks

No ${CHOST} works for me, but I was trying stuff to see if they would fix curmudgeon's issues. Thanks for all the info on how you got CHOST to work in your script. I found it very helpful. The new version that you posted right before I made that post is very stable and gcc-config actually works now. Before, I was using an older version where it didn't work.

The only thing I do is hack your script so it exits when a program fails to compile. I don't like skipping packages. Could I ask that you add something to your queue of things to do? I would like a switch that when enabled, the script would wait for user interaction on a failed program, like (R)etry, (S)kip, or (E)xit. You would have those three choices, so if a program fails, it can be taken care of right then and there. IF one is doing a very large update, skiping programs is hurtful because newer programs will be linked against the old program instead of the new one. If one is lucky then other programs that require the failed program are version dependent and will fail since the new version wasn't installed. However, if not, then one may need to run revdep-rebuild afterwards and that means double compiling. The default for asking those three choices would be off and one would need to add a commandline switch to emerge to be asked those choices.

Would this be doable?

Thanks for your hard work

PS. Thanks for not adding output like Update script has saying that I am l33t for running a ~x86 system. That got annoying.

Since he has a just "config" in that directory, the cause of the issue has been found. Glad I said that so he would list the directory contents. Very strange. Did older gcc's put config there instead of config-$CHOST? I wonder if any other user has just config there. :S

Did older gcc's put config there instead of config-$CHOST? I wonder if any other user has just config there. :S

I think (wouldn't bet on it, though) that you have it backwards.

All of my machines (including some installs within the last month) have config. I did find one config-$CHOST on a very old install. The file had a modification time more than two years ago, and referenced an old version of gcc long removed from the system.

Well thats wierd because I have one new install. It's config-${CHOST} and so is my other box. They are are both ~x86 as I have had fewer frustrations with it than stable. I read gcc-config while trying figure this out. There was only one mention of plain config the rest were config-CHOST. Go figure._________________An A-Z Index of the Linux BASH command line

emwrap.sh the wraper for emerge. Allows you to control when you update
your Tool Chain. Started adding the verson or r# to the end. EX:
emwrap.sh-r4 . When you select it to downloaad in your browser
and it gives you the option to "save as" remove the -r# and/or version
and hit ENTER.

oneliner_TCbuild.sh Builds the TC then the system files minus the TC files.
Use:run it and stand back. If you want to stop it start banging out CTRL+C.

cleanpkg.sh Cleans out your package files useing /var/db/pkg as a
current file listing. Removes anything not in it. Use: run it
with out args and gives simple instructions.

unmask.sh When you have alot of files to unmask,this automates puting them in to
/etc/portage/package.keywords. Usefull for KDE gnome xfce4.
Modified for other major unmasking projects like beagle.
Use: "unmask.sh kde p/-p" to see output. "unmask.sh kde' to do the
deed.

USE.sh a simple USE flag checker that will check 1 or more USE flags and if no
flags are passed reads your /etc/make.conf USE varible. This gives
way to much info EXCEPT that it prints on the last line dead USE flags.

and to think, yesterday I cleaned out some really old garbage and updated the README

by the way, hielvc, you haven't answered this question from me yet. *whistles*

StifflerStealth wrote:

The only thing I do is hack your script so it exits when a program fails to compile. I don't like skipping packages. Could I ask that you add something to your queue of things to do? I would like a switch that when enabled, the script would wait for user interaction on a failed program, like (R)etry, (S)kip, or (E)xit. You would have those three choices, so if a program fails, it can be taken care of right then and there. IF one is doing a very large update, skiping programs is hurtful because newer programs will be linked against the old program instead of the new one. If one is lucky then other programs that require the failed program are version dependent and will fail since the new version wasn't installed. However, if not, then one may need to run revdep-rebuild afterwards and that means double compiling. The default for asking those three choices would be off and one would need to add a commandline switch to emerge to be asked those choices.

StifflerStealth its neither good nor bad. Its a preference. My experince with -uDN is to just restart, not resume. With world or system -e that could get boring. I again go by my experince. Having stop, wouldn't have helped with the expat mess.

If I was to do it I would overload emerge_faild. The "stop" would be easy > tc_faild, first " if [ "${stop}" == "yes" ];then tc_faild". This leads to the real question, are you going to try and rebuild the pkg that failed. If so, are you going to do it first for all, or for only one specific stop, or after you go thru the 3 stop conditions. Maybe put in a test to see if boinc is running, stop it and sleep 5 minutes, then re-emerge the pkg, if successful restart boinc and then continue emwrap.sh. Post your your patch._________________An A-Z Index of the Linux BASH command line

1.) Rebuild everything THEN compile the kernel (so the kernel gets compiled with the latest version of everything).

2.) Build the new kernel first, reboot, and then recompile the system (so that everything gets linked against the new kernel).

If there are no bugs and no other toolchain upgrades, it doesn't matter: Since the kernel does not use glibc, the kernel binary will be the same, no matter whether built with old or new glibc. Since nothing gets linked against the kernel (except kernel modules), it plays no role at all whether or when you reboot.

If there are also other toolchain upgrades (gcc or binutils) simultaneously, you should compile the kernel not before upgrading these; and of course the kernel modules should be recompiled after the kernel upgrade (once more: Whether you boot the new kernel before building the modules or not doesn't mattter, because the built process is not influenced by the running kernel [of course, unless the kernel is buggy... or if you need some of the modules to get a running system]).

curmudgeon I thing your remembering the gcc-3 to gcc-4 change. The recomended way was to build the TC first then before you rebooted you needed to recompile your kernel. I dont remember anybody going "OOOhhh My Goood Im so fast now" it was that for some configs you couldnt or if it did boot, it had errors. In other words do last or do right after the TC didnt matter., just doing it did before shutdown did. I would rebuild everything before rebooting, particully if you're moving from gcc-3 to gcc-4. If your already using gcc-4 and your not going from glibc-2.4 to 2.6 if so rebuild allis _________________An A-Z Index of the Linux BASH command line

Hielvc quick question, I am fairly new to linux, and I recently used your script to build my system. gcc-config is showing 2 profiles,. gnu-3.3.6, and gnu-4.2.2, and the one being used is gnu-4.2.2. when i try to emerge certian packages (emul-linux-x86) they are being blocked by 3.3.6. What is the best way around this? Do I need to unmerge 3.3.6, or is it necessary for the system?

rach3kb I dont use 64bit but you can unmerge gcc-3.3.6 since you have gcc-4.2.2. For those who dont know you HAVE TO HAVE at least one gcc installed on your Gentoo system._________________An A-Z Index of the Linux BASH command line