CHOSTの変更
この文書は、既存のシステムの CHOST 変数を変更する方法について説明します。
CHOSTの変更は、システムをひどくめちゃくちゃにしてしまう可能性もある重大な事項です - それでは、なぜそのような大破壊をもたらす可能性のあることについてガイドがあるのでしょうか?
CHOST の変更が避けられない状況はいくつかあります。そうした状況のほとんどは、通常の操作では必要になることはないはずです (新しいアーキテクチャへのブートストラップを伴うのですから) 。しかしながら時として、プロファイルの切り換え、例えば MIPS マシンを 17.0 プロファイルから 23.0 プロファイルにアップグレードした場合は、設定を共通の標準に適合させるために、CHOST の変更を伴うことがあります。
ここに書かれた手順に従った場合でさえ問題は起こり得ますから、手順はきわめて慎重に読み、また実行してください。この例では CHOST 変数は mips64-unknown-linux-gnu から mips64-unknown-linux-gnuabin32 へと変更されます。コマンドは個別の状況に合わせて変えてください。
make.conf の更新
CHOST変数の変更を始めるには、まず/etc/portage/make.confファイルを編集してCHOSTの値を要件を満たすように追加/変更します。
/etc/portage/make.confCHOST="mips64-unknown-linux-gnuabin32"
プロファイルは CHOST のデフォルト設定を提供していることに注意してください; 状況に応じて、/etc/portage/make.conf 内でそれを上書きしたり、/etc/portage/make.conf 内の上書き設定を削除したりする必要があるかもしれません。どちらの場合でも、実効的な値が変更されていることが重要です。
プロファイルのデフォルトとは異なる CHOST 値を使用したい場合には、CHOST_${ABI} の値も同様に更新しなければならないかもしれないことに注意してください。現在設定されているプロファイルの変数の値は portageq ツールを使って調べることができます:
user $portageq envvar ABIn32
user $portageq envvar CHOST_n32mips64-unknown-linux-gnuabin32
この値が CHOST と一致していれば大丈夫です。そうでない場合にはそれも同様に書き換えてください:
/etc/portage/make.confCHOST_n32="mips64-unknown-linux-gnuabin32"
パッケージの構築
一般的に、パッケージをCHOSTの切り替え前と同じバージョンになるように再構築するのは良い考えです。すなわち、CHOSTの切り替えとアップグレードを組み合わせて行わないようにするということです。複数のスロットがインストールされている場合は無関係なスロットをアンインストールするか、またはすべてのスロットを再構築してください。これができない場合には、まず(古いCHOSTで)パッケージをアップグレードしてください。CHOSTの切り替えとアップグレードを組み合わせることは不可能ではないかもしれませんが、どのような潜在的問題点が発生するか予測することは困難であり、それをこのガイドに文書化することはほぼ不可能です。
CHOST の切り換えを、例えばプロファイルアップグレードなどの他の変更と同時に行う場合は、異なる手順が干渉しないように、そちらのドキュメンテーションもお読みください。
以下のパッケージを、この順番で再構築します:
root #emerge --ask --oneshot sys-devel/binutilsgccをコンパイルする前に、binutils-configを実行する必要があるかもしれません。
root #emerge --ask --oneshot sys-devel/gccglibc ベースのシステムでは:
root #emerge --ask --oneshot sys-libs/glibcmusl ベースのシステムでは:
root #emerge --ask --oneshot sys-libs/muslうまくいっているか確認する
gcc-configとbinutils-configの設定が正常か、また/etc/env.d/に残ってしまったものがないか、確認します。
gcc-configとbinutils-configの出力は以下のようになっている必要があります:
出力は、ことによると、あるいはおそらく、gcc のバージョンや CHOST の設定によって異なります。上の例では mips で gcc 12 を使用しています。
root #gcc-config -l[1] mips64-unknown-linux-gnuabin32-12 *
root #gcc-config -cmips64-unknown-linux-gnuabin32-12
root #binutils-config -l[1] mips64-unknown-linux-gnuabin32-2.39 * # binutils-config -c mips64-unknown-linux-gnuabin32-2.39
次に、/etc/env.d/に古いCHOSTへの参照がないか確認します:
root #cd /etc/env.d/
root #grep linux-gnu *04gcc-mips64-unknown-linux-gnu:MANPATH="/usr/share/gcc-data/mips64-unknown-linux-gnu/12/man" 04gcc-mips64-unknown-linux-gnu:INFOPATH="/usr/share/gcc-data/mips64-unknown-linux-gnu/12/info" 04gcc-mips64-unknown-linux-gnuabin32:MANPATH="/usr/share/gcc-data/mips64-unknown-linux-gnuabin32/12/man" 04gcc-mips64-unknown-linux-gnuabin32:INFOPATH="/usr/share/gcc-data/mips64-unknown-linux-gnuabin32/12/info" 05binutils:MANPATH=/usr/share/binutils-data/mips64-unknown-linux-gnuabin32/2.39/man 05binutils:INFOPATH=/usr/share/binutils-data/mips64-unknown-linux-gnuabin32/2.39/info
ここで、binutils に関しては問題ありません - 新しい CHOST への参照を含む 1 ファイルだけが存在しています。 gcc に関しては、新旧の CHOST 値それぞれに対応するファイルが存在しているので、古いほうを削除してください:
root #rm 04gcc-mips64-unknown-linux-gnubinutilsについても同様です - もし余分なものがあったら、どちらが古くなったものか見て削除します。続いて/etc/env.d/binutils/の内容を確認します:
root #cd /etc/env.d/binutils/
root #ls -ltotal 12 -rw-r--r-- 1 root root 13 Dec 9 22:16 config-mips64-unknown-linux-gnu -rw-r--r-- 1 root root 13 Dec 31 17:00 config-mips64-unknown-linux-gnuabin32 -rw-r--r-- 1 root root 117 Dec 31 16:59 mips64-unknown-linux-gnuabin32-2.39
root #cat config-mips64-unknown-linux-gnuabin32CURRENT=2.39
root #cat mips64-unknown-linux-gnuabin32-2.39TARGET="mips64-unknown-linux-gnuabin32" VER="2.39" LIBPATH="/usr/lib32/binutils/mips64-unknown-linux-gnuabin32/2.39"
古い CHOST を含む古いファイル、config-mips64-unknown-linux-gnu があるので、これを削除してください。
root #rm config-mips64-unknown-linux-gnugcc/ ディレクトリへと移動しましょう。
root #cd /etc/env.d/gcc# ls -l total 12 -rw-r--r-- 1 root root 36 Dec 30 11:31 config-mips64-unknown-linux-gnu -rw-r--r-- 1 root root 42 Dec 31 23:54 config-mips64-unknown-linux-gnuabin32 -rw-r--r-- 1 root root 353 Dec 31 23:52 mips64-unknown-linux-gnuabin32-12
root #cat config-mips64-unknown-linux-gnuabin32CURRENT=mips64-unknown-linux-gnuabin32-12
root #cat config-mips64-unknown-linux-gnuCURRENT=mips64-unknown-linux-gnu-12
root #cat mips64-unknown-linux-gnuabin32-12GCC_PATH="/usr/mips64-unknown-linux-gnuabin32/gcc-bin/12" LDPATH="/usr/lib/gcc/mips64-unknown-linux-gnuabin32/12" MANPATH="/usr/share/gcc-data/mips64-unknown-linux-gnuabin32/12/man" INFOPATH="/usr/share/gcc-data/mips64-unknown-linux-gnuabin32/12/info" STDCXX_INCDIR="g++-v12" CTARGET="mips64-unknown-linux-gnuabin32" GCC_SPECS="" MULTIOSDIRS="../lib32"
config-mips64-unknown-linux-gnuabin32 と mips64-unknown-linux-gnuabin32-12 は良さそうですが、もう 1 つの config-mips64-unknown-linux-gnu は残り物ですから削除する必要があります。
繰り返しますが、古い gcc バージョンへの参照を含んだファイルの名前は、異なる名前を持っているかもしれません。ファイルを名前だけでなく内容からも識別することが重要です。
root #rm config-mips64-unknown-linux-gnuそれでは、環境を更新するために以下のコマンドを実行します:
root #env-update && source /etc/profile次に、/etc/env.d 内のすべてが修正されたかどうか検証します。まだファイルがある場合は、次に進む前に原因を調査してみてください。
変更の仕上げ
ここで sys-devel/libtool を再度 emerge する必要があります:
root #emerge --ask --oneshot libtoolこれで、すべてのパッケージを再構築することができます:
root #emerge --ask --emptytree @world理論上はこれを行う必要はないはずですが、実際にそうだと 100% 保証することはできません。代わりに、問題があると知られているすべてのパッケージを手動で再構築することもできます:
- CHOST プレフィックスやヘッダーラッピングを使用している multilib パッケージ
- 設定済みコンパイラーのパスを記憶している Perl、Python およびその他のツール
root #emerge --ask --oneshot /usr/bin/mips64-unknown-linux-gnu-* /usr/include/mips64-unknown-linux-gnu /usr/lib/llvm/*/bin/mips64-unknown-linux-gnu-* dev-lang/perl dev-lang/python現在のシステムにあてはまらないパスについては、上のコマンドから取り除く必要があるかもしれないことに注意してください。
その他に再構築が必要なパッケージに遭遇したら、このガイドのdiscussion pageを通じて私達にお知らせください。
よくある問題
いまや問題はそう多くないはずです。本当に珍しい変更をしない限り、これまでの方法で通常は機能するでしょう。が、CHOST の変更と他の手順を組み合わせないようにしてください。以下のメモには非常に古いものも含まれています……。
CHOST変数の変更と同時にgcc 3.3から4.1にアップグレードする際(とにかくそれはしないでください)、数人のユーザーはsys-apps/groffやmail-mta/courierといった、再構築が必要な壊れたパッケージを報告しています:
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 のアップグレードガイドを参照してください。
まれに、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.