From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Changing the CHOST variable and the translation is 21% complete.
Outdated translations are marked like this.
Other languages:

本文档解释了如何更改现有系统的 CHOST 变量。

更改 CHOST 是一个大问题,可能会严重搞砸系统——那么,如果它会造成如此大的破坏,为什么会有此指南?

在某些情况下,更改 CHOST 变量是不可避免的,例如当升级到仅支持 NTPL 的 glibc 2.4 时,用户发现当前的 CHOST 是 i386,导致无法使用 NTPL。在这种情况下,没有很多选择,更改 CHOST 就是其中之一。

即使按照这些说明进行操作,也可能会出现问题,因此请务必仔细阅读并执行这些说明。在本例中,CHOST 变量将从 i386 更改为 i686。请根据具体情况更改命令。

要开始更改 CHOST 变量,请编辑 /etc/portage/make.conf 文件并添加/更改 CHOST 值以适应要求。

文件 /etc/portage/make.conf

Note that profiles provide a default setting for CHOST; depending on the situation, it may be necessary to override it in /etc/portage/make.conf or remove an override in /etc/portage/make.conf. In any case, the important point is that the effective value changes.

请注意,如果你计划使用其它 CHOST 值而不是特定配置文件默认值,你可能还需要更新 CHOST_${ABI} 变量。你可以通过“portageq”工具查询这些变量的当前值:

user $portageq envvar ABI
user $portageq envvar CHOST_x86

如果相应值等于你的 CHOST,那没问题。否则你应该覆盖它,例如:

文件 /etc/portage/make.conf


It is generally a good idea to rebuild the packages to the same versions as before the CHOST switch, i.e. avoiding combining upgrades with it. If multiple slots are installed, either uninstall extraneous slots or rebuild all of them. If that is not possible, please upgrade the packages first (with old CHOST). While it may not be impossible to do so, it is hard to predict which potential problems may arise and almost impossible to document them in this guide.
If the CHOST switch takes place together with other changes, e.g. in the course of a profile upgrade, please read the documentation there as well to make sure the different steps do not interfere.


root #emerge --ask --oneshot sys-devel/binutils
在编译 gcc 之前可能需要运行 binutils-config
root #emerge --ask --oneshot sys-devel/gcc
root #emerge --ask --oneshot sys-libs/glibc


Now it is time to make sure that the gcc-config and binutils-config settings are sane and that there are no leftovers in /etc/env.d/.

The output of gcc-config and binutils-config should look like the following:

输出可能,甚至会根据 gcc 版本和 CHOST 设置而有所不同。以下示例为在 i686 上使用 gcc 4.1.1。
root #gcc-config -l
 [1] i686-pc-linux-gnu-4.1.1 *
root #gcc-config -c
root #binutils-config -l
 [1] i686-pc-linux-gnu-2.16.1 *
# binutils-config -c

接下来,检查 /etc/env.d/ 中是否存在对旧的 CHOST 变量的引用:

root #cd /etc/env.d/
root #grep 386 *

Here, binutils is fine - there is one file, and it only contains references to the new CHOST. For gcc, there is a file for both the new and the old CHOST value, so delete the old stale one:

root #rm 05gcc-i386-pc-linux-gnu

The same also applies to binutils - if there's an extra one, see which is the outdated one and delete it. Next, check the contents of /etc/env.d/binutils/:

root #cd /etc/env.d/binutils/
root #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
root #cat config-i686-pc-linux-gnu
root #cat i686-pc-linux-gnu-2.16.1

那个看起来不错,那两个文件应该在那里。是时候进入 gcc/ 目录了。

root #rm config-mips64-unknown-linux-gnu

Time to move on to the gcc/ directory.

root #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
root #cat config
root #cat config-i386-pc-linux-gnu
root #cat mips64-unknown-linux-gnuabin32-12

config-mips64-unknown-linux-gnuabin32 and mips64-unknown-linux-gnuabin32-12 are fine, but config-mips64-unknown-linux-gnu is another leftover that needs removal.

Again, the name of the file containing references to an outdated gcc version may have a different name. It is important to identify the file on its content, not only the name.
root #rm config-i386-pc-linux-gnu


root #env-update && source /etc/profile



Now it is necessary to re-emerge sys-devel/libtool:

root #emerge --ask --oneshot libtool


root #emerge --ask --emptytree @world

In theory, it should not be necessary to do so, but it cannot be 100% guaranteed that this is actually the case. Alternatively, it is possible to manually rebuild all the known problematic packages:

  • multilib packages using CHOST prefixing or header wrapping,
  • Perl, Python and other tools that store configured compiler path.
root #emerge --ask --oneshot /usr/bin/i386-pc-linux-gnu-* /usr/include/i386-pc-linux-gnu /usr/lib/llvm/*/bin/i386-pc-linux-gnu-* dev-lang/perl dev-lang/python


When encountering other packages that need recompiling, please let us know through the discussion page of this guide.


Not so many anymore. Usually this just works, as long as no really exotic change is done. Make sure to not combine the CHOST change with other steps though. Some of the notes below are really old...

When upgrading from gcc 3.3 to 4.1 at the same time as changing the CHOST variable (please don't do that anyway), a couple of users reported broken packages that need recompiling, such as sys-apps/groff and mail-mta/courier:

代码 错误信息
error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

This happens because during the upgrade, the CHOST variable doesn't exactly match the CTARGET variable value, making the compiler assume that the system is using cross-compiling. As a consequence, LDPATH isn't inserted into ld.so.conf, resulting in this error.

Please see the GCC upgrade guide for what needs to be rebuilt after a GCC upgrade.

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 the old CHOST and gcc version) to /etc/ld.so.conf, running ldconfig and then emerge libstdc++-v3. However, as can be seen, this situation needs to be avoided - don't change CHOST and gcc at the same time.


That should be all, feedback (both if it worked, failed or other problems were encountered) is welcome, please use the discussion page or post to this forum thread. Much in this guide comes from vapier, thanks for the help!

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Wernfried Haas, Mike Frysinger (vapier) , Chris White
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.