2020年以降、AppleはMacのCPUをIntelアーキテクチャから64bit ARMアーキテクチャに移行しました。その際に、Intel用のバイナリコードをARM上で実行するためのRosettaというエミュレーション環境が提供されました。
しかし、前回の記事でも書いた通り、RosettaはmacOS 27が一般的なIntel Macアプリをサポートする最後のリリースとなり、それ以降は古いゲーム向けの限定的な機能のみが残るとアナウンスされています。
そこで、ちょっと気が早いですが、RosettaのないARMアーキテクチャのみの環境で、logue SDKの開発はどの程度行えるのか検証してみました。前提としては、Dockerは使わず、CLIでmakeすることとします。
以下、ubuntuと書いてある部分は、実際には前回の記事で紹介したcontainer machine上で動いているubuntu（aarch64）コンテナを指します。また、Homebrewでインストールされるコンパイラのバージョンは、2026年10月時点のものを利用していますが、将来別のバージョンに置き換わる可能性はあります。
結論から書いておくと、
・logue SDK v2 Cortex-M系列（NTS-1 mkII/NTS-3）： Homebrewでインストールできるcask版gcc-arm-embeddedでビルド可能。または、ubuntuにgcc-arm-none-eabi-10.3-2021.10をインストールしてビルドすることも可能。KORGのライブラリアン（Kontrol Editor）はmacOS上でARMネイティブ動作し、Rosetta不要。
・logue SDK v2 Cortex-A系列（drumlogue/microKORG2）： Linuxを前提としたMakefileになっているため、ubuntu上でSDKのdocker版ツールチェインをローカルに置いて利用するのが最も互換性が高い。container machineを使わずに、Homebrewでインストールできるarm-unknown-linux-gnueabihf-*系のツールチェインを使用してビルドすることも可能だが、その場合はMakefileの若干の修正が必要。
・logue SDK v1系列（prologue/NTS-1/minilogue xd）： Homebrewでインストールできるcask版gcc-arm-embeddedおよびubuntuのgcc-arm-none-eabi-10.3-2021.10でビルドは可能だが、KORGのライブラリアンを動作させるには現状ではRosettaが必要。
となりました。
なお、前回の記事ではubuntuが動作するようになっただけでしたが、開発に使用するには、追加で基本的な開発ツールをインストールする必要があります。私はこれまで使っていたx86上のubuntuから移行するため、以下のようにしてインストール済みパッケージの一覧を取得し
% apt-mark showmanual > packages-manual.txt
これを編集して不要なもの（VMWare用のツールなど環境依存のもの）を削除してから、
% while read pkg; do
sudo apt install -y "$pkg" || echo "FAILED: $pkg"
done < packages-manual.txt
のようにしてcontainer machine上のubuntuへパッケージをインストールしました。
また、準備としてgitをインストールして、logue SDKをgit cloneし、git submodule update --initしておくことは必要です。（submoduleに含まれているCMSISはユニットのビルドに必須です。）
以下、プラットホーム別の詳細です。
NTS-1 mkII / NTS-3
これらの２機種は組込用であるCortex-MアーキテクチャのMCUを採用したハードウェアで、開発にはCortex-M7のコードを生成するクロスコンパイラが必要です。
logue SDKで指定されているクロスコンパイラは、gcc-arm-none-eabi-10.3-2021.10です。このバージョンはx86版のバイナリは配布されていますが、macOSで動作するバイナリは無いようです。
クロスコンパイラを動作させる環境として、（１）macOS（２）container machine上のLinux の２つの候補がありますが、テストした限りでは、どちらでもlogue SDKユニットのビルドは可能です。
（１）macOS上でビルドする場合
Homebrewでクロスコンパイラをインストールします。
% brew install --cask gcc-arm-embedded
Homebrewでインストールしたコマンドは/opt/homebrew/binにありますので、ビルドの際にはMakefileで定義されているGCC_BIN_PATHにそのパスを与えます。
% make GCC_BIN_PATH=/opt/homebrew/bin install
2026年10月現在、インストールされるgccのバージョンは15.3.1でした。
% /opt/homebrew/bin/arm-none-eabi-gcc --version arm-none-eabi-gcc (Arm GNU Toolchain 15.3.Rel1 (Build arm-15.149)) 15.3.1 20260627
（２）ubuntuでビルドする場合
gcc-arm-none-eabi-10.3-2021.10は、aarch64用のバイナリが配布されていますので、これをubuntu上にインストールします。配布されているURLおよびハッシュ値は以下の通りです。
ARCHIVE_URL="https://developer.arm.com/-/media/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-aarch64-linux.tar.bz2" ARCHIVE_SHA1="5e540a115a0705a4c1fad32e163277ff63c3035a"
logue SDKのtools/gccにあるシェルスクリプトget_gcc_10_3-2021_10_macos.shを変更して、aarch64用のインストーラスクリプトを作成しましたので、こちらに置いておきます。
drumlogue / microKORG2
（１）macOS上でビルドする場合
Homebrewでクロスコンパイラをインストールします。drumlogueは内部でARM Cortex-A7 32bitのLinuxが動作していますので、Linux用のコードを生成するコンパイラが必要です。NTS-1 mkII/NTS-3用のコンパイラは使えません。
brew tap messense/macos-cross-toolchains brew install messense/macos-cross-toolchains/arm-unknown-linux-gnueabihf
また、macOSとLinuxのコマンドの違いやコンパイラの仕様の違いから、Makefileを一部修正する必要があります。左の部分を右のように直します。
100,101c100,101 < USE_COPT += -finline-limit=9999999999 < USE_COPT += --param max-inline-insns-single=9999999999 --- > USE_COPT += -finline-limit=2147483647 > USE_COPT += --param max-inline-insns-single=2147483647 104,105c104,105 < USE_CXXOPT += -finline-limit=9999999999 < USE_CXXOPT += --param max-inline-insns-single=9999999999 --- > USE_CXXOPT += -finline-limit=2147483647 > USE_CXXOPT += --param max-inline-insns-single=2147483647 278,279c278,279 < USER_ID := $(strip $(shell stat -c %u .)) < GROUP_ID := $(strip $(shell stat -c %g .)) --- > USER_ID := $(strip $(shell id -u)) > GROUP_ID := $(strip $(shell id -g))
CROSS_COMPILEにツールチェインのプレフィクスを与えてビルドします。
% make CROSS_COMPILE=/opt/homebrew/bin/arm-unknown-linux-gnueabihf- install
（２）ubuntuでビルドする場合
以前書いた記事と同じく、Dockerfileで指定されているツールチェインをローカルにダウンロードして、それを使ってビルドします。
このとき注意点は、ダウンロードしたtar.bz2形式のアーカイブファイルを展開する際に、通常のmacOSのファイルシステムではなく、container machine側のファイルシステムに展開することです。アーカイブファイルはLinuxのファイルシステムを前提としているので、macOSのファイルシステムに展開しようとするとパーミッションエラーが出て、うまく展開できずに失敗します。
前回の記事で、case sensitiveなファイルシステムの作成を紹介しましたが、case sensitiveであってもmacOSのファイルシステムはmacOSのファイルシステムであって、case sensitiveであるという点以外ではLinuxのファイルシステムとは異なります。
私の場合は、ツールチェインを/home/username/toolchainsに展開しました。
cp logue-sdk/docker/docker-app/builder/get_drumlogue_toolchain.sh ~/toolchains cd ~/toolchains ./get_drumlogue_toolchain.sh
これで、必要なツール一式が~/toolchains/arm-unknown-linux-gnueabihfに入ります。
ubuntuを使う場合は、Makefileは修正する必要はありません。ツールチェインへのプレフィクスは与える必要があります。
% make CROSS_COMPILE=~/toolchains/arm-unknown-linux-gnueabihf/bin/arm-unknown-linux-gnueabihf- install
prologue / NTS-1 / minilogue xd
これらのデバイスについては、logue SDKで指定されているツールチェインはgcc-arm-none-eabi-5_4-2016q3-20160926です。これはだいぶ古いもので、aarch64版のバイナリは配布されていません。
従って、Rosetta無しでツールチェインを整備しようとするなら、コンパイラ自体のビルドから始める必要があります。しかし、そこまで互換性を求めないのであれば、前述のNTS-1 mkII / NTS-3用にHomebrew経由でインストールできるcask版のツールチェイン、およびubuntu用のgcc-arm-none-eabi-10.3-2021.10でも一応ビルドができることは確認しました。
macOS上で
% make GCC_BIN_PATH=/opt/homebrew/bin install
でwavesをビルドし、できたユニットをNTS-1にロードしたところ、正常動作しました。
また、ubuntu上で
% make GCC_BIN_PATH=../../../tools/gcc/gcc-arm-none-eabi-10.3-2021.10/bin install
でビルドしたユニットについても、同じく正常動作しました。
ただし、ロードするためにはKORGのライブラリアンまたはlogue-cliツールを使う必要がありますが、これらはいずれもRosettaを必要とし、ARMネイティブでは動作しません。
オープンソースのツールで、Macからlogue SDK v1系列のデバイスにユーザーユニットを送信するツールとしては、elektroidがあります。これを以下のように試しにビルドして使ってみました。
% brew install automake libtool pkg-config gtk+3 libsndfile libsamplerate gettext zlib json-glib libzip rtaudio rtmidi rubberband librsvg % git clone https://github.com/dagargo/elektroid % cd elektroid % ./macos-bundle.sh % cp -r ./Elektroid.app /Applications
現状、ユニットの書き込み以外の操作（音色・プログラムの読み書きなど）はできませんが、ユニットの書き込み自体は問題なくできるようです。（結構クラッシュする頻度が高いですが）
macOSか、ubuntu on container machineか
というわけで、いずれのlogue SDK対応デバイスについても、64bit ARM環境のみ（Rosetta無し）で開発を行うことは”一応は”可能です。その方法としては
（１）macOSでHomebrewでインストールできるmacOS用クロスコンパイラを使う
（２）container machineでubuntuを動かし、その上で使えるLinux版クロスコンパイラを使う
の２つの系統があります。
ファームウェアがLinuxであるdrumlogue/microKORG2については、（２）の方が安心です。
Linux用にコンパイルされたバイナリは、Shared libraryと共に動作しますので、ファームウェアに含まれるShared libraryへの依存があります。そのため、コンパイラのsysrootに含まれるglibcと、ファームウェア側のglibcとのABI互換性を考慮する必要があります。特に、より新しいglibcを前提として生成されたバイナリでは、ファームウェア側に存在しないシンボルバージョンを要求してしまう可能性があります。しかしHomebrew版では、利用するツールチェインのバージョンが異なる可能性が（将来的にも）あります。（２）の方法であればツールチェインのバージョンを固定できます。
現状は、（１）（２）共に、試したdummy-synthについてreadelfで確認した範囲では、どちらのツールチェインで生成したバイナリも要求するglibcシンボルバージョンはGLIBC_2.4の範囲に収まっており、Homebrew版コンパイラでビルドしても互換性の問題は起きにくいようです（絶対に起きないとは言えませんが）。
Cortex-Mシリーズを使っているNTS-1/NTS-1 mkII/NTS-3/prologue/minilogue xdについては、drumlogue/microKORG2のようにターゲットOSのglibcとのABI互換性を考慮する必要はありません。NTS-1 mkII/NTS-3のユニット形式自体はELF shared objectですが、Linux上のshared libraryへの依存とは事情が異なります。従って基本的には、ツールチェインのバージョンによる違い自体は大きな問題にはならないはずです。
ただしコンパイラのバージョンによって、コンパイラに与えることができるオプションやそれによる動作が違ってくると、互換性に問題が出てきます。試した範囲では、Cortex-Mを採用するlogue SDK v1/v2デバイスについては、gcc-arm-none-eabi-10.3-2021.10でビルド可能なように見えます。
個人的には、これら組み込み系プロセッサのデバイスについても、（２）のubuntu on container machineの方をお勧めします。最初にcontainer machineを構築する手間はありますが、macOS+Homebrewを使うよりもビルドが体感的には高速なように感じます。また、Linuxなので各種コマンドのオプションの互換性エラーに遭遇する可能性が低いことも期待できます。
コメント