CHOSTの変更

This page is a translated version of the page Changing the CHOST variable and the translation is 100% complete.

Other languages:

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

はじめに

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

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

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

CHOST変数の変更

make.confの更新

CHOST変数の変更を始めるには、まず/etc/portage/make.confファイルを編集してCHOSTの値を要件を満たすように追加/変更します。

FILE /etc/portage/make.conf

CHOST="i686-pc-linux-gnu"

プロファイルのデフォルトとは異なる値を使用したい場合には、CHOST_${ABI}の値も同様に更新しなければならないかもしれないことに注意してください。これらの変数の現在の値はportageqツールを使って調べることができます:

user $portageq envvar ABI

x86

user $portageq envvar CHOST_x86

i686-pc-linux-gnu

この値がCHOSTと一致していれば大丈夫です。そうでない場合にはそれも同様に書き換えてください:

FILE /etc/portage/make.conf

CHOST_x86="i686-pc-linux-gnu"

パッケージの構築

Important
一般的に、パッケージをCHOSTの切り替え前と同じバージョンになるように再構築するのは良い考えです。すなわち、CHOSTの切り替えとアップグレードを組み合わせて行わないようにするということです。複数のスロットがインストールされている場合は無関係なスロットをアンインストールするか、またはすべてのスロットを再構築してください。これができない場合には、まず(古いCHOSTで)パッケージをアップグレードしてください。CHOSTの切り替えとアップグレードを組み合わせることは不可能ではないかもしれませんが、どのような潜在的問題点が発生するか予測することは困難であり、それをこのガイドに文書化することはほぼ不可能です。

Tip
CHOSTがi386の値に設定されているシステムでは、gccのアップグレードの間はi386で使用できないglibc 2.4(以降)をマスクしてください。アンマスクは変更を完全に実行してから行ってください。

以下のパッケージを、この順番で再構築します:

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-configとbinutils-configの設定が正常か、また/etc/env.d/に残ってしまったものがないか、確認します。

gcc-configとbinutils-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"

configとi686-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 --ask --emptytree @world

理論上はこれを行う必要はないはずですが、実際にそうだと100%保証することはできません。代わりに、問題があると知られているすべてのパッケージを手動で再構築することもできます:

CHOSTプレフィックスやヘッダーラッピングを使用しているmultilibパッケージ
設定済みコンパイラーのパスを記憶しているPerl、Pythonおよびその他のツール

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

あなたのシステムにあてはまらないパスについては上のコマンドから取り除く必要があるかもしれないことに注意してください。

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

よくある問題

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

CODE エラーメッセージ

error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

これは、アップグレードの間にCHOST変数がCTARGET変数と厳密に一致せず、コンパイラーがシステムはクロスコンパイルを利用中であると推定するために発生します。結果としてLDPATHがld.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.