spack

Homebrew が去り MacPorts が帰ってこない Intel Mac で eMudhra 中間証明書秘密鍵漏洩へ対策したパッケージマネージャーを bootstrap で組み上げる 注意: この記事は macOS Tahoe 26 が Apple からサポートされセキュリティアップデートが提供される期間内における使用環境の充実を目的としています。Apple が macOS Tahoe 26 のサポートを終了した以降には安全性を担保できません。 初出: 2026年10月30日 2026年10月は歴史的転換点となる情報セキュリティ事故多発の裏側で Intel Mac にも転換点が 世間で Mac と言えば Apple Silicon、高速演算とバッテリー持ちの良さに皆が夢中です。 しかし Intel Mac がどうしても必要という技術者も少数残っています。x86_64 Linux VM を動かす必要があるとか。 この記事を書いている2026年10月は情報セキュリティ事故が多発し歴史的転換点となりました。対策は、兎にも角にも、OS からアプリケーションまで安全なバージョンへの更新。 しかし、ここに来て Intel Mac には逆風が吹き始めました。ついに、と言うべきですが。 - Homebrew は Tier-3 サポートに移行し、新規パッケージ提供が停止 docs.brew.sh - MacPorts は本家サイトがメンテナンス中のまま（※2026年10月30日現在） macports.org じゃあ、どうする？ ということで、2026年10月末に利用できる資源で Intel Mac において eMudhra 中間証明書秘密鍵漏洩へ対策したパッケージマネージャーを bootstrap で組み上げました。その段取りを記します。前提として OS バージョンを macOS Tahoe 26.7.2 とします。 昨年に Qiita に大嘘を書き（恥ずかしくて、悔しくて、リンクは書けません）信用されない身です。さて、今回はどうか。再現できるよう記します。 Intel Mac にパッケージマネージャーを構築 Xcode 用コマンドラインツールパッケージをダウンロードしてインストール 環境を組み上げる途中でコンパイラと git コマンドが必要になります。それは Apple 純正のXcode 用コマンドラインツールパッケージをダウンロードしてインストールします。Apple 純正 dmg 形式ですから署名されており eMudhra 中間証明書秘密鍵漏洩から影響を受けません。macOS Tahoe 対応の範囲にバージョンを抑える必要があり、現在は Command Line Tools 26.6 Universal を選択します。 git コマンドが古いことは避けられません。後で対策を打ちます。 - developer.apple.com （日本語ページタイトルが中途半端なので割愛……） go コンパイラを pkg 形式でダウンロードしてインストール 後で asdf を使用できるよう、go コンパイラをインストールします。go 1.27.3 は eMudhra 中間証明書秘密鍵漏洩にランタイムで対策済みです。pkg 形式をダウンロードすれば署名されており eMudhra 中間証明書秘密鍵漏洩から影響を受けません。 - Download and install - The Go Programming Language 環境変数 GOPATH を固定値で設定 一般的な go コンパイラインストールでは環境変数 GOPATH を go env GOPATH コマンドにより取得しますが、ここでは固定値で設定します。go コマンドを実行しなくても値が確定していることが重要です。 ~/.zshrc に次の設定を追記します。 export GOPATH=$HOME/go export PATH="$PATH:$GOPATH/bin" .zshrc 修正を反映させます。 $ exec $SHELL -l ルート証明書ストアファイル /etc/ssl/cert.pem にワークアラウンドを実施 「どうせ、やると思った」という声が聞こえてきそうです。古い git コマンドを使用する以上、仕方ありません。 - About the compromised eMudhra intermediate CAs - Apple Support asdf を go コマンドでインストール macOS に asdf をインストールする際には Homebrew を使用するのが一般的ですが、素の go コンパイラを使用してもインストールできます。go 1.27.3 をインストールしているので eMudhra 中間証明書秘密鍵漏洩にランタイムで対策済みです。 asdf が依存するのは次のコマンドです。参照: Dependencies | asdf - Bash version 3.2.48 - Git version 1.7.7.2 Xcode 用コマンドラインツールパッケージをインストールした macOS Tahoe 26.7.2 は条件を満たすと分かります。 your_account@yyy ~ % /bin/bash --version GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin25) Copyright (C) 2007 Free Software Foundation, Inc. your_account@Yyyy ~ % /usr/bin/git --version git version 2.50.1 (Apple Git-155) asdf をインストールする go コマンドは以下です。 $ go install github.com/asdf-vm/asdf/cmd/asdf@v0.20.2 ~/.zshrc に次の設定を追記します。 export PATH="${ASDF_DATA_DIR:-$HOME/.asdf}/shims:$PATH" .zshrc 修正を反映させます。 $ exec $SHELL -l Python を asdf 経由でインストール asdf を使用できるようになり Python をインストールできます。Python 3.14.10 は eMudhra 中間証明書秘密鍵漏洩にランタイムで対策済みです。 $ asdf plugin add python $ asdf install python 3.14.10 $ asdf set -u python 3.14.10 Spack をインストール 僕は Spack というパッケージマネージャーがあることを初めて知りました。知らない人が多いと推測します。スパコン向け計算プログラムを開発する研究者をメインターゲットとして管理されており、開発に必要なコマンド、例えば curl、git、openssh などは一通り揃っています。私たちに嬉しいのは Intel Mac サポートを継続していることです。 - Spack インストールに python3 しかも新しい版を要求します。先に asdf 経由で Python 3.14.10 をインストール済みですから、インストール可能です。 インストール手順を詳しく説明してくださった遺伝研に感謝いたします。参照: spack 自体のインストール手順 ただし git clone のみ GitHub にある README.md より借りました。参照: spack/spack 次のコマンドを実行します。 $ cd $HOME $ git clone --depth=2 https://github.com/spack/spack.git ~/.zshrc に次の設定を追記します。 export SPACK_ROOT=/Users/your_account/spack source $SPACK_ROOT/share/spack/setup-env.sh .zshrc 修正を反映させます。 $ exec $SHELL -l pkg 形式でインストールした go コンパイラをアンインストールし、go コンパイラを Spack 経由でインストール Go という言語が持つ特徴は、Unix プラットフォーム向け実行バイナリを動的リンクライブラリに依存しないモノシリックな構造で出力することです。先ほどインストールした asdf 実行ファイルは macOS 標準以外の動的リンクライブラリに依存しません。ですから生みの親である go コンパイラをアンインストールしても asdf コマンドは動作します。 your_account@Yyyy ~ % otool -L /Users/your_account/go/bin/asdf /Users/your_account/go/bin/asdf: /usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libresolv.9.dylib (compatibility version 0.0.0, current version 0.0.0) かつ Spack は go コンパイラをバージョン管理可能です。 この二つから、pkg 形式でインストールした go コンパイラをアンインストールし、go コンパイラを Spack 経由でインストールすると go コンパイラがパッケージマネージャー管理下に置かれます。なおかつ環境変数 GOPATH を固定値で設定しましたから go コンパイラの実行バイナリを入れ替えた前後で asdf など go がインストールするコマンドのパスが変わりません。 pkg 形式でインストールした go コンパイラをアンインストール // Source - https://stackoverflow.com/a/57634196 // Posted by arcseldon, modified by community. See post 'Timeline' for change history // Retrieved 2026-10-29, License - CC BY-SA 4.0 $ sudo rm -rf /usr/local/go $ sudo rm /etc/paths.d/go go コンパイラを Spack 経由でインストール $ spack install go@1.27.3 Spack の特徴として管理下のコマンドは spack load コマンドで指定しないと PATH に現れません。常に使用できるよう .zshrc に次の設定を追記します。 spack load go .zshrc 修正を反映させます。 $ exec $SHELL -l ここまでの作業により依存関係が円環を形成しました。そして総じて CUI コマンドにより更新可能です。ですから全てがパッケージマネージャーの管理下に置かれスクリプトによる更新が可能となったのです。 asdf <---+ | | v | python3 | | | v | spack | | | v | go ------+ 英語のことわざで "pull oneself up by one's bootstraps" とは「自分のブーツの取っ手を引っ張って自分を持ち上げる」という不可能を意味しますが、pkg 形式でインストールした go コンパイラから遊離して自分達だけで上昇していける環境が整ったのです。現実に。 Nodejs を asdf 経由でインストール asdf をインストールしたのですから Node.js をインストールできます。円環に加わることない枝となります。 $ asdf plugin add nodejs $ asdf install nodejs 24.22.2 $ asdf set -u nodejs 24.22.2 ここまでくると asdf + pip + npm + Spack により、Intel Mac 上に開発環境を管理するパッケージマネージャーを構築できました。 残課題 /etc/ssl/cert.pem のワークアラウンドを取り消すか これは各自のリスク管理で違いが出ます。 例えば curl は2026年10月30日現在で最新リリースが2026年10月14日と eMudhra 中間証明書秘密鍵漏洩より以前ですから対策は入っていません。参照: curl releases

Spackの使い方 Spackとは Spackは、科学技術計算向けソフトウェアを管理するパッケージマネージャーです。各ソフトウェア（パッケージ）について、バージョン、コンパイラ、依存ライブラリ、ビルドオプションが異なる構成を容易に共存させることができます。構成の単位をspecと呼びます。 Spack的に正しい用語か自信はありませんが、本稿では以下の用語を用います。 - パッケージ：Spackに登録されている（インストール可能な）アプリケーションソフトウェア - spec：パッケージに設定を反映してインストールした、利用可能な構成 オブジェクト指向に例えると、パッケージはクラス、specはインスタンス、です。パッケージとspecの関係は、一対多です（多重継承はありません）。 例えば、HDF5（パッケージ）のMPI対応版と非対応版を、それぞれ別のspecとして区別してインストールできます。 以下、３つのパートに分けて使い方を説明します。 - （システムに）導入済みのSpackを利用する - 自分でSpackをインストールした後、アプリケーションをインストールする - アプリケーションをSpack対応する ここで説明する他にも、豊富な機能が用意されています。公式ドキュメントも参照してください。 spack.readthedocs.io 導入済みのSpackを利用する （管理者に）指定された Spack の初期化スクリプトを読み込みます。 パス(/path/to/spack/)を実際のインストール場所に読み替えてください。 source /path/to/spack/share/spack/setup-env.sh 初期化スクリプトは、新しいターミナルを開く度に読み込みます。 Bashの起動（ログイン）時に読み込む場合は、~/.bashrc に先のコマンドを追加します。 spackコマンドが利用できることを確認します。 # バージョンとヘルプの確認 spack --version spack --help インストール済みspecの一覧を表示します。 spack find -x # ハッシュ値付きで表示 spack find -lx オプションなしのspack findは、依存しているspec含めて全て表示します。ほとんどの場合、ロードするのは-x付きで表示されるspecだろうと思います。利用したいspecが見つかれば、ロードします。 spack load openmx 同じ名前のspecが複数ある場合は、ハッシュ値で区別します。 spack load /abcdefg ロード済みのspec一覧を表示します。 spack find --loaded ロード済みのspecを、アンロードします。 spack unload openmx 自分でSpackを導入する Spackをインストールする前に、対応しているアプリケーション（パッケージ）をWebで検索できます。 packages.spack.io Spack本体のインストール Spackは、管理者権限不要で各種アプリケーション（パッケージ）を簡単にインストールできます。 まず、Spack本体を準備します。 # 開発版をインストール。インストール先は、`./spack` git clone --depth=2 https://github.com/spack/spack.git # インストール先を指定する場合 git clone --depth=2 https://github.com/spack/spack.git "$HOME/spack" # バージョンを指定する場合 git clone --branch v1.2.0 -depth=2 https://github.com/spack/spack.git # 環境設定 source "$HOME/spack/share/spack/setup-env.sh" # 動作確認 spack --version Bashの起動（ログイン）時に読み込む場合は、~/.bashrc に次の行を追加します。 source "$HOME/spack/share/spack/setup-env.sh" 外部コンパイラの確認 ソースからのビルドには、（ほとんどの場合）コンパイラが必要です。 検出・登録したのち、一覧を確認します。 # PATH 上のコンパイラを検出・登録 spack compiler find # 登録済みコンパイラを表示 spack compiler list spack compilers パスが通っていれば、oneAPIのコンパイラを自動で認識します。けれども、CUDAのコンパイラは見つけてくれない、ようです。 spack external find cuda CUDAのコンパイラが認識されていることを確認します。 spack config get packages アプリケーションのインストール spack list は、Spackに用意されている（インストール可能な）パッケージの一覧を表示します。 spack.readthedocs # 全パッケージ spack list # 候補を絞り込む spack list vim 興味あるパッケージがあれば、説明を確認します。 spack info neovim パッケージ名を指定してインストールします。 # NVIDIA HPC SDK spack install nvhpc # AMD Optimizaing C/C++ and Fortran Compilers (AOCC) spack install aocc +license-agreed aoccのインストールには、+license-agreedオプションが必要です。 aoccのinfoから抜粋します。 （前略） Variants: build_system [generic] generic Build systems supported by the package license-agreed [false] false, true Confirm acceptance of the EULA (https://www.amd.com/en/developer/aocc/aocc-compiler/eula.html) （後略） インストールには、ライセンス(EULA)への同意が必要です。license-agreedの既定値はfalseなので、「同意」する場合は、先頭に+を付与します（trueを指定）。逆に、既定値がtrueの項目(variant)をfalseに変える場合は、先頭に~（チルダ）を付与します。 複数バージョンのインストール LAMMPSには様々なオプション(variants)が用意されています。 spack info lammps 利用する機能に応じたオプションを追加してインストールします。 specコマンドで具体的に選ばれる構成を確認できます。 # 確認のみ、インストールしない spack spec lammps ~mpi # OpenMPを無効にして、ReaxFFを有効にする（試した環境ではOpenMPIが利用されました） spack install lammps ~openmp +reaxff # Intel oneAPIのコンパイラとMPIを使う、並列数を制限 spack install -j 4 lammps %oneapi ^intel-oneapi-mpi -jオプション指定無しで、並列インストールします。スパコンのフロントエンドなど、他者と共有している計算機では、並列数を制限したほうが良いでしょう。 ハッシュ値付きで、インストール済みspecの一覧を表示します。 $ spack find -lx -- linux-ubuntu26.04-haswell / %c,cxx,fortran=oneapi@2026.1.1 --- rx5zjl7 aocc@5.2.0 -- linux-ubuntu26.04-haswell / %c,cxx=gcc@15.2.0 ---------------- mid2ggg lammps@20250722.3 -- linux-ubuntu26.04-haswell / %c,cxx=oneapi@2026.1.1 ----------- k52i4rr lammps@20250722.3 -- linux-ubuntu26.04-haswell / no compilers --------------------- xxdohip nvhpc@26.3 ==> 5 installed packages oneAPIでコンパイルされたLAMMPSを使うには、以下のコマンドを実行します。 # lammpsは二つあるので、ハッシュ値を指定 spack load /k52i4rr なお、インストールされたspecの所在は、以下のコマンドで得られます。 # パッケージ名をしてしても良い spack location -i /k52i4rr アプリケーションのアンインストール 不要になったspecをアンインストールします。 spack uninstall lammps 依存するspecを含めて削除します。 spack uninstall -R lammps 不要になったライブラリなどを削除します。 spack gc 全てのspecを削除します。やり直したくなったときに使います。 spack uninstall --all 作業用のディスク領域が不足する場合 特別に指定しなければ、コンパイル作業は/tmpディレクトリで実行されます。/tmpに十分な容量が割り当てられていなければ、ディスク領域が不足する恐れがあります。 作業ディレクトリは、Spack設定ファイル~/.spack/config.yamlで指定できます。このファイルは、直接テキストエディタで編集できそうですが、専用のコマンドが用意されていますので、そちらを用いたほうが良いでしょう。 spack config edit config config: build_stage: - ~/tmp oneAPI依存パッケージのインストールを止める （意図して）インストールしたspecの他に、依存するspecが自動的にインストールされます。その中には、Intel oneAPI関係のパッケージ(spec)が含まれます。 - intel-oneapi-runtime - intel-oneapi-mpi これらに相当するものが、（Spackとは無関係に）システムにインストールされている場合、重複してインストールするのは無駄に感じられます。これらを外部化（externals）すれば、パッケージのインストールを抑制できます。 spack config edit packages packages: intel-oneapi-mpi: externals: - spec: intel-oneapi-mpi@2021.18 prefix: /opt/intel/oneapi buildable: false intel-oneapi-runtime: externals: - spec: intel-oneapi-runtime@2026.1 prefix: /opt/intel/oneapi/compiler/2026.1 buildable: false oneAPIを優先して使用する :::note warn 以下設定は、何らかの作用がありますが、私は、解決困難なエラーに遭遇しました。（少なくとも不慣れな方は）利用を控えたほうが良いでしょう。再検討予定。 ::: Intel系のCPUを搭載した計算機では、（CUDA, ROCmを使わない場合に；GNUコンパイラでなく）oneAPIの利用を優先したいと思います。それも、packages.yamlで設定可能です。 packages: all: providers: mpi: [intel-oneapi-mpi] c: prefer: - intel-oneapi-compilers cxx: prefer: - intel-oneapi-compilers fortran: prefer: - intel-oneapi-compilers 未対応アプリケーションをSpack対応させる 既存のパッケージを参考にする 既存のパッケージの格納場所は、以下コマンドで調べられます。 spack location -p openmx このようなファイルで構成されています。主な作業は、package.pyを整えることです。 $ ls $(spack location -p openmx) __pycache__ for_aarch64.patch package.py package.py編集のためのコマンドも用意されています。 spack edit openmx リポジトリの用意 作業用のリポジトリを用意します。 # 一つ目の引数がディレクトリ名、二つ目の引数がnamespace spack repo create ~/spack_repo_local local spack repo add ~/spack_repo_test/spack_local/local spack repo list # removeで、リポジトリを削除 # spack repo remove local # レポジトリを指定 spack list -r local パッケージ作成 パッケージの雛形を作成します。 spack create --name bader --namespace local --template makefile https://theory.cm.utexas.edu/henkelman/code/bader/download/bader.tar.gz package.pyを整えます。 spack edit bader UbuntuのGNU Fortranで（は）動くようになりました。 from spack_repo.builtin.build_systems.makefile import MakefilePackage from spack.package import * class Bader(MakefilePackage): """Bader charge analysis of charge-density grids.""" homepage = "https://theory.cm.utexas.edu/henkelman/code/bader/" url = "https://theory.cm.utexas.edu/henkelman/code/bader/download/bader.tar.gz" version( "1.05", sha256="8dcc32a17b8caf11622347ed89924edb6cebbee63bfd7bf30e752f0fb402aa25", ) depends_on("fortran", type="build") # This recipe uses GNU Fortran compiler flags. conflicts( "%oneapi", msg="This recipe currently supports GNU Fortran only.", ) # Fortran module dependencies may not support parallel make. parallel = False def edit(self, spec, prefix): if self.compiler.name != "gcc": raise InstallError("This recipe currently supports GNU Fortran only.") copy("makefile.osx_gfortran", "Makefile") def install(self, spec, prefix): mkdirp(prefix.bin) install("bader", prefix.bin) 意図した動作をしない場合 デバッグ情報を表示します。 spack -d install -v bader 参考にしました qiita.com