‎한국어この文書は、既存のシステムのCHOST変数を変更する方法について説明します。それでは、なぜそのような大破壊をもたらす可能性のあることについてガイドがあるのでしょうか?CHOSTの変更が避けられない状況はいくつかあります。2.4へアップグレードするときに現在のCHOSTがNTPLを使用できないi386であることに気づいた場合などです。このケースではとりうる選択肢はあまり多くはなく、そしてCHOSTの変更はその1つです。これらの手順に従った場合でさえ問題は起こり得ますから、手順はきわめて慎重に読み、また実行してください。i686へと変更されます。コマンドは個別の状況に合わせて変えてください。CHOST変数の変更make.confの更新CHOST変数の変更を始めるには、まず/etc/portage/make.confファイルを編集してCHOSTの値を要件を満たすように追加/変更します。/etc/portage/make.confCHOST="i686-pc-linux-gnu"プロファイルのデフォルトとは異なる値を使用したい場合には、CHOST_${ABI}の値も同様に更新しなければならないかもしれないことに注意してください。CHOST_x86i686-pc-linux-gnuこの値がCHOSTと一致していれば大丈夫です。/etc/portage/make.confCHOST_x86="i686-pc-linux-gnu"パッケージの構築Important一般的に、パッケージをCHOSTの切り替え前と同じバージョンになるように再構築するのは良い考えです。CHOSTの切り替えとアップグレードを組み合わせて行わないようにするということです。複数のスロットがインストールされている場合は無関係なスロットをアンインストールするか、またはすべてのスロットを再構築してください。これができない場合には、まず(古いCHOSTで)パッケージをアップグレードしてください。CHOSTの切り替えとアップグレードを組み合わせることは不可能ではないかもしれませんが、どのような潜在的問題点が発生するか予測することは困難であり、それをこのガイドに文書化することはほぼ不可能です。2.4(以降)をマスクしてください。アンマスクは変更を完全に実行してから行ってください。sys-devel/binutilsNotegccをコンパイルする前に、binutils-configを実行する必要があるかもしれません。sys-libs/glibcうまくいっているか確認するgcc-configとbinutils-configの設定が正常か、また/etc/env.d/に残ってしまったものがないか、確認します。gcc-configとbinutils-configの出力は以下のようになっている必要があります:Note出力は、ことによると、あるいはおそらく、gccのバージョンやCHOSTの設定によって異なります。4.1.1を使用しています。*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のようになっているかもしれません。余分なものがあったら、どちらが古くなったものか見て削除します。i686-pc-linux-gnu-2.16.1TARGET="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/ディレクトリへと移動しましょう。i686-pc-linux-gnu-4.1.1PATH="/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といった異なる名前を持っているかもしれません。ファイルを名前だけでなく内容からも識別することが重要です。/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が当てはまります。@world理論上はこれを行う必要はないはずですが、実際にそうだと100%保証することはできません。dev-lang/pythonあなたのシステムにあてはまらないパスについては上のコマンドから取り除く必要があるかもしれないことに注意してください。pageを通じて私達にお知らせください。directoryこれは、アップグレードの間にCHOST変数がCTARGET変数と厳密に一致せず、コンパイラーがシステムはクロスコンパイルを利用中であると推定するために発生します。結果としてLDPATHがld.so.confに挿入されずにこのエラーが発生します。guideを参照してください。まれに、pythonの古いバージョンも破壊されることがあります。libstdc++-v3を実行することによって修復されることがあります。CHOSTとgccは同時に変更しないでください。フィードバックしてください以上です、フィードバック(動いた、失敗した、あるいはその他の問題に遭遇した、のいずれも)は歓迎します。pageを利用するか、このフォーラムスレッドに投稿してください。