CHOSTの変更

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Changing the CHOST variable and the translation is 79% complete.

Other languages:
English • ‎español • ‎français • ‎日本語 • ‎한국어 • ‎русский • ‎中文(中国大陆)‎

この文書は、既存のシステムのCHOST変数を変更する方法について説明します。

はじめに

CHOSTの変更は、システムをひどくめちゃくちゃにしてしまう可能性もある重大な事項です - それでは、なぜそのような大破壊をもたらす可能性のあることについてガイドがあるのでしょうか?

たとえば、nptlのみをサポートするglibc 2.4へアップグレードするときに、現在のCHOSTがnptlを使用できないi386であることに気づいた場合のように、一定のCHOSTの変更が避けられない状況があります。このケースではとりうる選択肢はあまり多くはなく、そしてCHOSTの変更はその1つです。

これらの手順に従った場合でさえ問題は起こり得ますから、手順はきわめて慎重に読み、かつ実行してください。この例ではCHOST変数はi386からi686へと変更されます。コマンドはそれぞれの状況に合わせて変えてください。

CHOST変数の変更

Updating make.conf

To start out with the CHOST variable change, edit the /etc/portage/make.conf file and add/change the CHOST value to suit the requirements.

FILE /etc/portage/make.conf
CHOST="i686-pc-linux-gnu"

Please note that if you are planning to use another value of CHOST than the profile default, you may need to update the CHOST_${ABI} variable as well. You can query the current value of these variable via portageq tool:

user $portageq envvar ABI
x86
user $portageq envvar CHOST_x86
i686-pc-linux-gnu

If this value is equal to your CHOST, you're good. Otherwise, you should override it as well, e.g.:

FILE /etc/portage/make.conf
CHOST_x86="i686-pc-linux-gnu"

パッケージの構築

Important
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 you have multiple slots installed, either uninstall extraneous slots or rebuild all of them. If you can't do that, 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.
Tip
On a system with CHOST set to an i386 value, mask glibc 2.4 (or newer) during the gcc upgrade as it cannot be used with i386. Unmask it once the change has been performed completely.

Rebuild the following packages in this order:

root #emerge --ask --oneshot sys-devel/binutils
Note
gccをコンパイルする前に、binutils-configを実行する必要があるかもしれません。
root #emerge --ask --oneshot sys-devel/gcc
root #emerge --ask --oneshot sys-libs/glibc

うまくいっているか確認する

gcc-configbinutils-configの設定が正常か、また/etc/env.d/に残ってしまったものがないか、確認します。

gcc-configbinutils-configの出力は以下のようになっている必要があります:

Note
出力は、ことによると、あるいはおそらく、gccのバージョンやCHOSTの設定によって異なります。上の例ではi686でgcc 4.1.1を使用しています。
root #gcc-config -l
 [1] i686-pc-linux-gnu-4.1.1 *
root #gcc-config -c
i686-pc-linux-gnu-4.1.1
root #binutils-config -l
 [1] i686-pc-linux-gnu-2.16.1 *
# binutils-config -c
i686-pc-linux-gnu-2.16.1

次に、/etc/env.d/に古いCHOSTへの参照がないか確認します:

root #cd /etc/env.d/
root #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"
Note
すべてのケースでこれが起こるわけではありませんが、このケースでは05gcc-i386-pc-linux-gnuは古いCHOSTの値への参照を含んでいます。CHOSTをどの値からどの値へ変更するのかによって、システムごとに状況は異なります。ある場合には、参照がまったく残らないこともあります。名前は、05gcc-new_CHOST-pc-linux-gnuのようになっているかもしれません。

それらのファイルを削除する前に、更新されたCHOSTの値を含むファイルを確認しておきましょう:

root #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"

こちらが正しいファイルのようであり、/etc/env.d/内にはgcc向けのファイル(この例では05gcc)は常に1つだけ存在しているべきなので、誤った参照を含むものは削除しておきます:

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

binutilsについても同様です - もし余分なものがあったら、どちらが古くなったものか見て、削除します。続いて、/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
CURRENT=2.16.1
root #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"

これら2つのファイルはここに存在しているはずであり、こちらは大丈夫そうです。gcc/ディレクトリへと移動しましょう。

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
CURRENT=i686-pc-linux-gnu-4.1.1
root #cat config-i386-pc-linux-gnu
CURRENT=i386-pc-linux-gnu-4.1.1
root #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"

configi686-pc-linux-gnu-4.1.1は良さそうですが、もう1つのconfig-i386-pc-linux-gnuは残り物ですから、削除する必要があります。

Note
さらに、古いgccバージョンへの参照を含んだファイルの名前は、たとえばシステムが(この例では)i686へ変更されているにもかかわらずconfig-i686-pc-linux-gnuといった、異なる名前を持っているかもしれません。ファイルを名前だけでなく、内容からも識別することが重要です。
root #rm config-i386-pc-linux-gnu

それでは、環境を更新するため、以下のコマンドを実行します:

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

次に、すべてが修正されたかどうか検証します:

root #grep -r 386 /etc/env.d/

まだファイルが見つかる場合、続行する前にそれらを探し出すようにします。

変更の仕上げ

ここで、sys-devel/libtoolを再度emergeし、/usr/share/gcc-data/$CHOST/<gcc-version>/にあるfix_libtool_files.shを実行する必要があります。正しいバージョン(現在のもの、ここでは4.1.1)のgccを使用していること、古いアーキテクチャ(ここではi386)を引数として渡していることを確認してください。$CHOSTは新しいCHOSTの値に、また<gcc-version>はgccのバージョンに置き換えてください。この例では、CHOSTにはi686が当てはまります。

root #emerge --ask --oneshot libtool
root #/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/fix_libtool_files.sh 4.1.1 --oldarch i386-pc-linux-gnu

これで、すべてのパッケージを再構築することができます:

root #emerge -e world

In theory, it should not be necessary to do so, but it cannot be 100% guaranteed that this is actually the case. Alternatively, you can 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

Note that you may need to remove paths that do not apply to your system from the above invocation.

その他に再構築が必要なパッケージに遭遇したら、このガイドのdiscussion pageを通じて私達にお知らせください。

よくある問題

CHOST変数の変更と同時にgcc 3.3から4.1にアップグレードする際(とにかくそれはしないでください)、数人のユーザーはsys-apps/groffmail-mta/courierといった、再構築が必要な壊れたパッケージを報告しています:

CODE エラーメッセージ
error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

これは、アップグレードの間に、CHOST変数がCTARGET変数と厳密に一致せず、コンパイラーがシステムはクロスコンパイルを利用中であると推定するために発生します。結果として、LDPATHld.so.confに挿入されず、このエラーが発生します。

GCCのアップグレード後に再構築が必要なものについては、GCC upgrade guideを参照してください。

まれに、pythonの古いバージョンも破壊されることがあります。これは、/etc/ld.so.conf/usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6(CHOSTとgccのバージョンに応じて変更してください)を追加し、ldconfig、そしてemerge libstdc++-v3を実行することによって修復されることがあります。しかしながら、ここに見られるように、こうした状況は避けられるべきです - CHOSTとgccは同時に変更しないでください。

フィードバックしてください

もちろん、フィードバック(動いた、失敗した、あるいはその他の問題に遭遇した、のいずれも)は歓迎します。discussion pageを利用するか、このフォーラムスレッドに投稿してください。このガイドの多くはvapierによるものです、協力に感謝します!


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.