Intel→Mシリーズ間でTime Machine(Mac標準の移行ツール)で環境を移行したら、Intelベースの開発環境とARMベースの開発環境の両方が残って競合します。それは表層では分からず、原因を地の底まで掘り進める地獄が待っています。
(AIと一緒に解決目指して頑張りましょう。)
MacでローカルLLMを動かそうとして、以下のpythonライブラリをpip installやらhomebrewやらで入れてみました。
- ollama(ローカルLLM実行をホストするやつ)
- TkEasyGUI(デスクトップアプリのGUIを作れる便利ライブラリ)
まずは、TkEasyGUIの方が、どうにもこうにも動きませんでした。
そして、AIの助言を借りて開発環境をきれいにしていたら、今度はollamaの方が動かなくなったりしました。
普通に再度homebrewで入れて、コマンドを叩いたら「存在しねぇよ」みたいなエラーが出まして。
何が起こっているのか分からず、再度消して入れ直したりしてもダメでして。
パスを書き換えたりしてみたら、また別の箇所が延々「依存関係が崩れてる」エラーを吐くみたいな状況になりました。
挙げ句の果てに、homebrewを消して入れ直せという命令も来るようになりまして、これはおかしいぞと気づき。
これをAIに助言させて解析してみたら、かなり根が深い問題だということがわかり、根っこから解決してこの記事を書くに至ります。
端的に言えば、Intel/ARMの各CPUをベースとする、開発環境の競合です。
私のMac遍歴は下記の通りで、移行時はTime Machineを使っていました。
- Intel Mac(MacBook 2015)
- M1 Mac(MacBook Air 2020)
- M4 Mac(MacBook Pro 2025)
当時はそんなにガッツリ開発で使っていなかったので気づきませんでしたが、IntelのCPUベースの開発環境と、Mシリーズチップベースの開発環境は土台から異なるようです。
そして、Intel Mac時代に構築された開発環境と、そこからM1 Mac移行時に作成された開発環境が混在し、今のM4環境へ載せ替えて色々開発しているときにそれが顕在化しました。
前提として、土台となるCPUが違うとその上に乗る開発環境が違ってきます。
レイヤー1:CPU
※ここは直接的に操作はしないのですが、前提知識として持っておくと吉。
- 元々IntelのCPU
- MシリーズはARMベースのCPU
以下、「パスを通す/消す」という表現の時には下記のファイルを書き換えます。
# ユーザーごとの設定。
# export PATH="〜:$PATH" を書くのは基本ここ。
nano ~/.zshrc
# ログインシェル用の初期化ファイル。
# .zshrc より前に読み込まれる。
nano ~/.zprofile
レイヤー2:パッケージマネージャー(homebrew)
- Intel 時代: /usr/local/Homebrew
- Mシリーズ時代: /opt/homebrew
- 解決策:Intel時代のhomebrewをアンインストールしてから、パスを削除し、Mシリーズのパスのみ通るようにした。
レイヤー3:ライブラリ(Tcl/Tk)
Tcl/Tk は GUI の基盤ライブラリですが、厄介なことに以下の複数が混在していました。
どれを消す/残すかというより、どれを Python に掴ませるかを調整する必要があります。
- Intel Homebrew 配下の Tcl/Tk(消せる。Time Machine 移行で残骸として残っていた)
- Homebrew (ARM) で入れた Tcl/Tk 9.0(使いたいバージョン)
- macOS 標準の Tcl/Tk 8.5(OS 組み込みで消せない)
対策:Intel残骸を消した上で、Python が古い Tcl/Tk (macOS 標準) を参照しないよう、Homebrew Tcl/Tk 9.0 にパスを通して再ビルドする。
レイヤー4:言語実行環境(pyenvでビルドされるPython)
-
pyenv で Python をビルドするとき、下層の Tcl/Tk ライブラリ に依存する。
-
macOS標準版を掴むと Tkinter 8.5
-
ARMで入れた版を掴むと Tkinter 9.0
-
解決策:下記を参照。(長いので…)
- Python (pyenv) をビルドするときに、下層のライブラリを探す。
- 優先順位は PATH, LDFLAGS, CPPFLAGS, PKG_CONFIG_PATH の設定で決まる。
- 設定が不十分だと、Homebrew の 9.0 ではなく システム標準の 8.5 を掴んでしまう。
- その結果、import tkinter でエラーやクラッシュが発生する。
- 下記コマンドを打って、目的に合った方(今回は9.0)を掴めているかを確認する。
python -c "import tkinter; print(tkinter.TkVersion)"
- ちなみに依存関係は以下の通り。
Homebrew (パッケージ基盤) ── Tcl/Tk 9.x
└─ Python (pyenvでビルドされる)
└─ Tkinter
macOS (標準組み込み) ── Tcl/Tk 8.5
└─ Python (pyenvでビルドされる)
└─ Tkinter
レイヤー5:アプリケーション(目に見えるエラーはここが原因に見える)
- TkEasyGUI (GUI系) → Python + Tkinter に依存
- ollama の Python バインディング → Python 環境に依存
- 上の何かが噛み合っていないとエラーになるという、表層からは分からない地獄絵図だった。
- 噛み合ってないエラーを、ひたすらAIにログを渡して解析してもらい、どんどん解決すべし。
表層で出た謎のエラーが、昔のCPUの種類に依存して発生していたと分かりました。
解決しないと動かないとは、諸々自力でやろうとすると大変でもあり、実践的な学びにもなるところですね。
そして、「とりあえずこんなエラー出たんだけど」で雑にグイグイ突き進めたので、やっぱりAIってすごい。
皆さんもIntelからMシリーズに乗り換えの際は、CPU起因で起こる開発環境の競合にご注意を!
Views: 0