みなさん、こんにちは。
前回、Haiku R1/beta6は「IoTオーケストレーションOS」としてのポテンシャルを秘めているものの、lm3s6965のFreeRTOSデモはQEMU側のイーサネット未実装という落とし穴で詰む、というお話を掲載しました。
今回はその続編です！
HaikuでRISC-Vクロスコンパイラを作ろうとした理由
前回の検証で lm3s6965 の罠を踏んだ結果、ネットワーク通信を行うなら「FreeRTOS + RISC-V virtデモ」の組み合わせが正解だとわかりました。これを進めるには、以下のツールチェーンが必要になります。
- riscv64-unknown-elf-binutils
- riscv64-unknown-elf-gcc
- newlib
FreeRTOSの「RISC-V virtデモ」を動かすため、まずはHaikuのパッケージマネージャ（pkgman）でツールチェーンを探してみたのですが、残念ながらARM用などはあるものの、riscv64 用のベアメタルツールチェーン（riscv64-unknown-elf-gcc）は公式リポジトリに存在しませんでした。
pkgman にパッケージがない以上、Haiku上でソースコードからコンパイルするしかありません。「Linuxなら10分で終わる作業だけど、Haiku上でやってみたらどうなるだろう？」と思い、実験してみることにしました。
その結果、案の定、「深い沼」に落ちてしまいました……。
binutilsは通る。しかしGCCとnewlibで大苦戦……
まずは結果からお話しすると、素直な手順ではすんなりいきませんでした。
| コンポーネント | Haikuでの手動ビルド結果 |
| binutils | 通る（–disable-sim –disable-gdb の指定が必須） |
| GCC | 途中で GCC_NO_EXECUTABLES となり、本体が生成されない |
| newlib | 前段のGCCが未完成のためコンパイルエラー（suffix判定不可） |
binutils はオプションを指定することで問題なくビルドできました。
しかし、GCC と newlib のビルドで一気に雲行きが怪しくなってきたのです。
なぜ手動ビルドで引っかかってしまったのか？
1. configureが「実行ファイルを作れない」と判断してしまう
GCCのビルド中、configureスクリプトが「ホスト環境で実行可能ファイルを生成できるか」というテスト（link test）を行います。
Cライブラリ（newlib）が存在しないベアメタル向けGCCの初期ビルドでは、リンクテストが失敗して GCC_NO_EXECUTABLES というフラグがセットされるのは正常な挙動なのですが、Haikuの標準ツールチェーンが持つPIE（位置独立実行形式）関連の挙動や依存関係も複雑に絡み合い、結果として gcc 本体が正しく生成されない状態に陥ってしまいました。
2. fixincludesで止まる
fixincludes は「ホストOSのヘッダーを修正する」仕組みですが、HaikuのPOSIXヘッダー構造は通常のLinux等と大きく異なります。そのためMakefileが適切に作成されず、install の段階でエラーになってしまいました。
make[1]: *** No rule to make target 'install'. Stop.※ベアメタル向けの場合は –disable-fixincludes を指定して回避するのが一般的です。
3. lto-pluginのリンクエラー
GCCのインストール時、lto-plugin を組み込もうとする段階で libiberty.a が見つからず落ちてしまいました。
ld: cannot find ../libiberty/libiberty.anewlibがビルドできなかった理由
newlib のconfigureは、「ターゲット用のGCC（この場合は xgcc）が正常にリンクまで動くこと」を前提にテストを行います。
しかし、前段のGCCが完全な状態になっていなかったため、newlib のconfigureチェックで弾かれてしまいました。
configure: error: cannot compute suffix of object files: cannot compileこれはnewlib自体のバグというより、ベアメタル特有の「段階的ビルド（Cライブラリがない状態からどう組み上げるか）」の手順と、Haiku上のビルド環境の相性にハマってしまったのが原因でした。
今回の学び
残念ながら目的を達成することはできず、沼から抜け出せなかったのですが、Haikuの現状を知るにはよい学びの時間でした。
- Haikuは「親機」としてやっぱり魅力的
- 軽量・シンプル・リアルタイム性・NVMM仮想化・メタデータFSという構成は、他にはない唯一無二の魅力です。
- ベアメタルGCCの手動ビルドは一筋縄ではいかない
- Linux上で慣れた感覚で configure && make を叩くだけでは、ベアメタル特有の段階的ビルドの落とし穴やHaiku固有のヘッダー処理に阻まれてしまいます。
- RISC-Vの仮想環境を構築するための現時点での最適解
- HaikuPortsにRISC-V用のクロスコンパイラがまだ用意されていない以上、無理にHaiku上でセルフビルドしようとせず、クロスコンパイル環境（Linux等）でバイナリを用意するか、HaikuPortsにレシピが追加されるのを待つのが賢い選択と言えそうです。
一見すると遠回りに見えますが、こうしたトラブルシューティングを通してOSやツールチェーンの裏側の仕組みが見えてくるのが、マイナーOS探訪の醍醐味ですね。
「Haikuを親機とし、外部で作られたRTOSイメージをNVMM上でオーケストレーションする」という本来のゴールに向けて、引き続き実験を続けていきたいと思います！
今回のような検証、「うちの環境ではどうなんだろう？」と気になった方はいませんか。
ビューローみかみでは、構想段階の壁打ちからPoC・実装・現場導入まで、現場で「使い続けられる」ものづくりを支援しています。
技術顧問サービスでは、本記事のような技術的な質問・検証にも継続的にお答えしています。「相談したら契約」ということはありません。システムを作らない判断も含めて、率直にお話しします。
▶ 技術顧問サービスの詳細はこちら
気になることがあればお気軽にご相談ください。
本日も最後までお読みいただきありがとうございました。
それでは、よいHaikuライフを！
