| View previous topic :: View next topic |
| Author |
Message |
tadamec
n00b
Joined: 15 Sep 2004
Posts: 5
|
 Posted: Thu Sep 30, 2004 5:47 pm Post subject: Changing CHOST Safe? |
 |
|
Hey, all.
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?
Thanks! |
|
| Back to top |
|
 |
Deranger
Veteran
Joined: 26 Aug 2004
Posts: 1215
|
| Posted: Thu Sep 30, 2004 5:50 pm Post subject: |
|
|
| AFAIK you shouldn't change CHOST unless you're installing from stage 1. |
|
| Back to top |
|
|
tadamec
n00b
Joined: 15 Sep 2004
Posts: 5
|
| Posted: Thu Sep 30, 2004 5:51 pm Post subject: |
|
|
Wow... That was quick...
Thanks for the info. I guess I'll stick with the i386 chost and -march=i686 then. |
|
| Back to top |
|
|
Deranger
Veteran
Joined: 26 Aug 2004
Posts: 1215
|
| Posted: Thu Sep 30, 2004 5:54 pm Post subject: |
|
|
You're welcome 
From Gentoo handbook:
| Quote: |
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.
|
|
|
| Back to top |
|
|
tadamec
n00b
Joined: 15 Sep 2004
Posts: 5
|
| Posted: Tue Oct 05, 2004 12:02 am Post subject: |
|
|
I did see that in the handbook, but since it was in the installation portion of the guide, I wasn't sure if that applied after finishing the installation.
Thanks again. Maybe I'll see if I can figure out some wording that would have made it a bit more clear in my case and see what the doc maintaners have to say about it.
Thanks again! |
|
| Back to top |
|
|
Kathars!s
Tux's lil' helper
Joined: 29 Sep 2004
Posts: 78
|
| Posted: Tue Oct 05, 2004 10:23 am Post subject: |
|
|
dumb question:
wouldn't it be possible to change the CHOST and then
| Code: | | emerge --emptytree world |
?
| Code: | --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.
|
but it seems for me that simply everything is emerged, also libc:
| Code: | # emerge -pe world | grep libc
[ebuild N ] sys-libs/glibc-2.3.3.20040420-r1
[ebuild N ] dev-libs/libcroco-0.5.1
[ebuild N ] sys-libs/libcap-1.10-r3
|
or do i misunderstand s.th. ? please make it clear |
|
| Back to top |
|
|
amne
Bodhisattva
Joined: 17 Nov 2002
Posts: 6378
Location: Graz / EU
|
| Posted: Wed Oct 20, 2004 6:47 pm Post subject: |
|
|
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"
|
Hope that clears things up.
PS: Moved from IG to Portage and Programming. |
|
| Back to top |
|
|
danielrendall
n00b
Joined: 09 Apr 2003
Posts: 11
Location: Leamington Spa, England
|
| Posted: Fri Apr 01, 2005 10:15 pm Post subject: Changing CHOST causes untold aggravation... |
|
|
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. |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3374
Location: USA
|
| Posted: Fri Apr 01, 2005 11:13 pm Post subject: |
|
|
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.
| Code: |
# emerge glibc binutils gcc
# emerge glibc binutils gcc
# emerge -e system
# emerge -e world
|
doing things this way, i've never encountered problems. just be very careful to be absoltely certain that you have everything set properly in make.conf or you could really b0rk your system.
the method i've used is a selective adaptation of robmoss' method, which essentially does the same thing but requires more compile time.f | Code: | emerge -e system
emerge -e system
emerge -e world
emerge -e world |
|
|
| Back to top |
|
|
Darknight
Guru
Joined: 26 Jan 2004
Posts: 483
Location: Italy
|
| Posted: Sat Jul 23, 2005 2:07 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
canal
Apprentice
Joined: 28 Sep 2004
Posts: 203
|
| Posted: Sat Jul 23, 2005 11:54 pm Post subject: |
|
|
| Darknight wrote: | 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"?
|
Yes - if you are noob. It's quite easy to screw system badly while doing it. In almost all cases it's possible to recover somehow but usually it's hard for novice.
| Darknight wrote: |
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. |
There are few spots where power outage will be disastorus but window of vulnerability is few seconds out of few hours of the whole process. YMMV.
P.S. I've done change few time. Just treat your system as "freshly unpacked stage1 tarball" - and use handbook. bootstrap.sh and so on (this is exactly what bootstrap.sh is designed for, after all!). |
|
| Back to top |
|
|
jsosic
Guru
Joined: 02 Aug 2004
Posts: 510
Location: Split (Croatia)
|
| Posted: Wed Aug 03, 2005 1:36 am Post subject: |
|
|
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  |
|
| Back to top |
|
|
softchill
n00b
Joined: 28 Jun 2003
Posts: 73
Location: Quebec, Canada
|
| Posted: Tue Aug 09, 2005 6:55 pm Post subject: |
|
|
| jsosic wrote: | | 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.
It's late, but just in case anyone else get on that thread  |
|
| Back to top |
|
|
knopper
Tux's lil' helper
Joined: 20 Apr 2002
Posts: 106
Location: The Netherlands
|
| Posted: Tue Nov 08, 2005 8:42 pm Post subject: |
|
|
| Bob P wrote: |
| Code: |
# emerge glibc binutils gcc
# emerge glibc binutils gcc
# emerge -e system
# emerge -e world
|
|
You think this will work when switching from ix86 to amd64 ? |
|
| Back to top |
|
|
Akaihiryuu
l33t
Joined: 08 May 2003
Posts: 794
Location: Columbus, OH
|
| Posted: Tue Nov 08, 2005 10:39 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
erikm
l33t
Joined: 08 Feb 2005
Posts: 634
|
| Posted: Tue Nov 08, 2005 11:40 pm Post subject: |
|
|
| knopper wrote: | | Bob P wrote: |
| Code: |
# emerge glibc binutils gcc
# emerge glibc binutils gcc
# emerge -e system
# emerge -e world
|
|
You think this will work when switching from ix86 to amd64 ? |
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.
Good luck! |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9614
Location: beyond the rim
|
| Posted: Wed Nov 09, 2005 5:25 am Post subject: |
|
|
| knopper wrote: | | Bob P wrote: |
| Code: |
# emerge glibc binutils gcc
# emerge glibc binutils gcc
# emerge -e system
# emerge -e world
|
|
You think this will work when switching from ix86 to amd64 ? |
No |
|
| Back to top |
|
|
knopper
Tux's lil' helper
Joined: 20 Apr 2002
Posts: 106
Location: The Netherlands
|
| Posted: Wed Nov 09, 2005 7:50 am Post subject: |
|
|
| Is there a standard procedure to do that without completely reinstalling? |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9614
Location: beyond the rim
|
| Posted: Wed Nov 09, 2005 8:06 am Post subject: |
|
|
| knopper wrote: | | 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 |
|
| Back to top |
|
|
Akaihiryuu
l33t
Joined: 08 May 2003
Posts: 794
Location: Columbus, OH
|
| Posted: Sun Nov 13, 2005 3:03 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3374
Location: USA
|
| Posted: Sun Nov 13, 2005 3:20 am Post subject: |
|
|
| ErikM wrote: | | 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. |
|
| Back to top |
|
|
Nicias
Guru
Joined: 06 Dec 2005
Posts: 446
|
| Posted: Sat Dec 10, 2005 3:08 am Post subject: |
|
|
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")
Thanks. |
|
| Back to top |
|
|
Bob P
Advocate
Joined: 20 Oct 2004
Posts: 3374
Location: USA
|
| Posted: Sat Dec 10, 2005 3:43 am Post subject: |
|
|
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? |
|
| Back to top |
|
|
paluszak
Apprentice
Joined: 28 Jun 2004
Posts: 266
Location: Warsaw, Poland
|
| Posted: Sun Dec 11, 2005 4:12 pm Post subject: Re: Changing CHOST causes untold aggravation... |
|
|
| danielrendall wrote: | | 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).
Jakub |
|
| Back to top |
|
|
rev138
l33t
Joined: 19 Jun 2003
Posts: 848
Location: Vermont, USA
|
| Posted: Mon Dec 12, 2005 2:40 pm Post subject: |
|
|
Shit... I changed my CHOST from i686 to i586, then ran | Code: | | # emerge -e system && emerge -e world |
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: | Code: | # emerge -e system
/usr/bin/python: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory |
I looked, and libstdc++.so.6 does exist in /usr/lib/gcc/3.4.4/i586-pc-linux-gnu/. I tried symlinking that to /usr/lib/gcc/3.4.4/i686-pc-linux-gnu/, but it didn't make a difference.
I tried | Code: | | # fix_libtool_files.sh 3.4.4 --oldarch i686-pc-linux-gnu |
But I get the same python error.
Please help!
Thanks. |
|
| Back to top |
|
|
|
Portage & Programming
