Changing the CHOST is a big issue that can seriously screw up your system - so why is there a guide for that it at all?
There are certain situations where changing the CHOST is inevitable, e.g. if you want to upgrade to glibc 2.4 which only supports nptl and you find out that your CHOST is i386, which makes it impossible to use nptl. In this case, you don't have a lot of options, and changing CHOST is one of them.
Even if following these instructions problems may arise, so please make sure to read and execute them very carefully. In this example the CHOST will be changed from i386 to i686, it is likely you do another change, please change the commands accordingly.
To start out with the CHOST change, edit the file
# emerge -av1 binutils gcc glibc
Now it is time to make sure that your
The output of gcc-config and binutils-config should look like this (may differ according to your gcc version and chost, gcc 4.1.1 and i686 here):
# gcc-config -l [1] i686-pc-linux-gnu-4.1.1 * # gcc-config -c i686-pc-linux-gnu-4.1.1 # binutils-config -l [1] i686-pc-linux-gnu-2.16.1 * # binutils-config -c i686-pc-linux-gnu-2.16.1 #(Now take a look around /etc/env.d/) # cd /etc/env.d/
Next, check to see if there are references to the old CHOST:
# grep 386 * 05gcc-i386-pc-linux-gnu:PATH="/usr/i386-pc-linux-gnu/gcc-bin/4.1.1" 05gcc-i386-pc-linux-gnu:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/4.1.1"
Before deleting the file, let's check for files with the updated CHOST:
# grep 686 * 05binutils:MANPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/man 05binutils:INFOPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/info 05binutils:LDPATH=/usr/i686-pc-linux-gnu/lib 05gcc:PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1" 05gcc:ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1" 05gcc:MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man" 05gcc:INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info" 05gcc:LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.1.1"
This one looks good as there should always be only one file for
# rm 05gcc-i386-pc-linux-gnu
The same also applies to
# cd /etc/env.d/binutils/ # ls -la total 8 -rw-r--r-- 1 root root 15 Sep 3 13:48 config-i686-pc-linux-gnu -rw-r--r-- 1 root root 126 Sep 3 13:48 i686-pc-linux-gnu-2.16.1 # cat config-i686-pc-linux-gnu CURRENT=2.16.1 # cat i686-pc-linux-gnu-2.16.1 TARGET="i686-pc-linux-gnu" VER="2.16.1" LIBPATH="/usr/lib/binutils/i686-pc-linux-gnu/2.16.1" FAKE_TARGETS="i686-pc-linux-gnu"
That one looks good, those two files actually should be there. Time to move on to the gcc directory.
# cd /etc/env.d/gcc # ls -la total 12 -rw-r--r-- 1 root root 32 Sep 3 16:43 config -rw-r--r-- 1 root root 32 Aug 3 14:25 config-i386-pc-linux-gnu -rw-r--r-- 1 root root 292 Sep 3 16:43 i686-pc-linux-gnu-4.1.1 # cat config CURRENT=i686-pc-linux-gnu-4.1.1 # cat config-i386-pc-linux-gnu CURRENT=i386-pc-linux-gnu-4.1.1 # cat i686-pc-linux-gnu-4.1.1 PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1" LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.1.1" GCCBITS="32" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info" STDCXX_INCDIR="g++-v4"
# rm config-i386-pc-linux-gnu
now run:
# env-update && source /etc/profile
Then verify everything is fixed:
# grep -r 386 /etc/env.d/
If you still find something, you must have missed some file, try to track it down before going on.
Now it is necessary to re-emerge
# emerge -av1 libtool # fix_libtool_files.sh 4.1.1 --oldarch i386-pc-linux-gnu
You may want to run:
# emerge -e world
Now, in theory it should not be necessary to do so, but it can not be 100% guaranteed that this is actually the case. ;-) If you do not recompile the world target, i've been told at least some packages need recompiling, so you should do:
# emerge -av1 python
All packages using perl install to the CHOST directory and hence need remerging. In case you haven't installed qfile, you will need to install app-portage/portage-utils first
# emerge -av portage-utils # emerge -av1 `qfile /usr/lib/perl* -Cq | sort -u`
If you encounter other packages that need recompiling, please let me know at the the email below.
When upgrading from gcc 3.3 to 4.1 at the same time as changing the CHOST (please don't do that anyway), a couple of users reported broken packages that need recompiling, such as groff and courier:
error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directoryThis happens because during the upgrade, the CHOST doesn't exactly match CTARGET and the compiler assumes cross-compiling. As a consequence LDPATH isn't inserted into ld.so.conf, resulting in this error.
Please see
In some rare cases, this can break old versions of python, too. This may be fixed by adding /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6 (change accordingly to your old chost and gcc version) to /etc/ld.so.conf, running ldconfig and then emerge libstdc++-v3. However, as you can see you really should avoid running into this problem - don't change CHOST and your gcc version at the same time.
That should be all, feedback (both if it worked, failed or other problems
were encountered) is welcome, please send an email to