I've got a newly installed system at a colo facility and the vendor has installed an x86 stage2 with the CHOST set to 'i386-pc-linux-gnu'. Unfortunately, it's an Athlon XP box, so I'd like to tweak a little bit.

Is it safe for me to update the CHOST to 'i686-pc-linux-gnu', emerge world, rebuild the kernel and run from there?

Warning: Although it might be tempting for non-stage1 users, they should not change the CHOST setting in make.conf. Doing so might render their system unusable. Again: only change this variable if you use a stage1 installation.

--emptytree (-e short option)
Virtually tweaks the tree of installed packages to only contain
libc, this is great to use together with --pretend. This makes
it possible for developers to get a complete overview of the
complete dependency tree of a certain package.

This question has been asked every now and then, here's the definitive answer (thanks, rac):

Quote:

20:38 <@rac> amne: the definitive answer to changing the CHOST setting is "if you're going to do it, you had better be about to (re)compile everything on your box"
20:38 <@rac> so that means either "at the start of an install" or "planning to emerge -e world"

I thought I'd change my CHOST from i586-pc-linux-gnu to i686-pc-linux-gnu. This has turned out to be something of a mistake since it now causes random build failures - usually an error message:

Code:

gcc-config error: Could not run/locate "i586-pc-linux-gnu-gcc"

Lots of things seem to have ended up with the string 'i586-pc-linux-gnu' hardcoded into them. So far, the fixing process has gone like this:

1) Re-emerge gcc (and binutils) - seems to be OK.
2) emerge -e system - failed on groff (re-emerging xorg-x11 fixed this, bizarrely) and also on dev-python/python-fchksum-1.7.1 ('fixed' by editing /usr/lib/python2.3/config/Makefile to change the 'CC' line - eventually Python will re-emerge and fix this properly). I'm currently at this stage.
3) Check to see which files in /bin, /usr/bin, /sbin, /lib, /usr/lib etc. have the string in them, use qpkg to find their owners and re-emerge them. I could emerge -e world but there are 520 packages (KDE, Gnome and OpenOffice amongst them) and I don't fancy this idea much...

I'm optimistic that it will be possible to recover the system from changing CHOST but it will involve seeing which packages don't compile, then applying crude hacks to scripts etc. to remove hardcodings of the old CHOST.

yes, you can change the CHOST setting, but you have to know what you're doing before you do it. i would recommend that you take precautions beyond those that rac has mentioned regarding recompiling everyting with the emerge -e option.

personally, when i change a CHOST setting, i rebuild the toolkit twice redundantly, and then i rebuild the world files with the newly built toolkit.

So comes the noob question of the day
I have a working system, I have an ok make.conf and I want to change chost to i686.
Do I have to make a backup "just in case"?
Do I have to fear a reboot in the middle of the process? (forced by power outage or such things)
I plan to follow Bob P's method.

So guys, hope you all remember this thread. I have one question... I'm on i686-pc-linux-gnu, and I would like to switch back to i386. Does this mean that only compiler will be built for i386, or all my applications that I compile later? Does CFLAGS and CXXFLAGS override CHOST? Thing is, I would like to use distcc, but my debian box doesn't have i686 but i386 compiler

So guys, hope you all remember this thread. I have one question... I'm on i686-pc-linux-gnu, and I would like to switch back to i386. Does this mean that only compiler will be built for i386, or all my applications that I compile later? Does CFLAGS and CXXFLAGS override CHOST? Thing is, I would like to use distcc, but my debian box doesn't have i686 but i386 compiler

You can use crossdev to have a 2nd compiler. That way you'll be able to compile for both machines and I think distcc will manage to get the right compiler.

You can change the CHOST setting, but if you do so, you will have to start with bootstrap and then emerge -e world. Just emerge -e world after changing CHOST will result in many things being broken if you don't bootstrap. You basically have to start over with stage 1. I've always set my own CHOST, but then I also build all my systems from stage 1.

Last edited by Akaihiryuu on Wed Nov 09, 2005 2:58 am; edited 1 time in total

My experiences of changing the CHOST is pretty much like everyone else's - it is possible, there is just a lot of tricky pitfalls. I only have two things to add:

1. For His Noodly Appendages sake, if you have a working system, make binary backups of the toolchain, emerge and python using quickpkg (man quickpkg) before you start screwing with make.conf. Backup gcc, glibc, binutils, portage and python, and libstdc++-v3, if you use it, that is.
2. Like Bob P, I rebuild my toolchain twice with the new CHOST setting before even starting with the emerge -e's, but with one addition: If you don't also rebuild python with the new CHOST, your emerge -e's will fail when python-fchksum looks for python in paths hardcoded with the old CHOST.

Is there a standard procedure to do that without completely reinstalling?

As far as I know: no. Really, trying such a thing on a live system will get you in serious trouble and isn't worth it.
If you have enough (unpartitioned) space my recommendation is just to do a secondary install and just copy the config.

Last edited by Genone on Sun Nov 13, 2005 6:23 am; edited 1 time in total

If you absolutely need an operational Linux system with things like X while you're doing the stage 1 install, I recommend using Knoppix. I've installed several systems by partitioning the drive, chrooting into it from a Knoppix shell, and starting bootstrap from there. Works great, and you have a fully operational X/KDE install while you're waiting.

2. Like Bob P, I rebuild my toolchain twice with the new CHOST setting before even starting with the emerge -e's, but with one addition: If you don't also rebuild python with the new CHOST, your emerge -e's will fail when python-fchksum looks for python in paths hardcoded with the old CHOST.

python hates a toolkit update in so many ways that its just evil.

you're right about the python-fchksum problem. one way around it is to do the python rebuild as you've mentioned. another way is to just to a complete toolkit system rebuild like this instead of the "abbreviated" method that i mentioned earlier:

Code:

emerge -e system
emerge -e system
emerge -e world
emerge -e world

the advantage of doing the redundant emerge -e system commands is that they'll purge the statically retained libraries out of all of your packages, including python._________________.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks

Ok, this is kind of an old post, but I currently have the same problem. I have a machine with a Celeron CHOST set to i386. So looks like I will be changin CHOST, and running two "emerge -e system"s and two "emerge -e world"s. I'm fine with all of that.

My questions (and intuitions) are as follows:

A) Do I need to rebuild the kernel? (I think yes)
B) If so when? (I think between the second "emerge -e system"s and the first "emerge -e world")

you don't HAVE to rebuild your kernel -- rebuilding an entire system using the static kernel on a Live CD is a good example that you don't HAVE to do it.

but then you have to ask yourself one question -- if you're going to go through all of the trouble to completely rebuild all of the system files on your system to effect a toolkit upgrade, why would you NOT want to apply that upgrade to the kernel as well, by rebuilding the kernel as the final step in the upgrade?_________________.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks

Lots of things seem to have ended up with the string 'i586-pc-linux-gnu' hardcoded into them.

It's a pretty old thread, but I thought I'd throw in my $.02. There's a scpript called fix_libtool_files.sh (installed with gcc) which fixes some hardcoded library paths. You can get a short info if you run it without params.

You can also try to emerge gcc, binutils and glibc with new CHOST value and then run revdep-rebuild to check which libraries are missing.

If python or something complains about missigng files/libs or whatever you can try to fix it temporarily with symlinks (ie. make a link i585... to i686... if you're upgrading from i586 to i686).

Unfortunately, the emerge failed on glibc (something about not finding '___thread'. I think it was due to having the 'nptlonly' USE flag on. I took the flag out, and tried to start again, but now python (and thus portage) is broken. I get the following: