1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

VirtualBox(6) VirtualBoxのHaikuにてHaikuをビルド

Last updated at Posted at 2020-01-15

はじめに

前回は、Ubuntu Budgie 20.04 に、VirtualBox(仮想化ソフトウェア)をインストールして、ゲストOS にHaiku をインストール しました。

今回は、OS であるHaiku 自体をビルドしてみました。簡単に(でもないけど)OS がコンパイルできる環境を準備できているのがすごいですね。コミュニティで開発されているだけのことはあります。

当然ながら今回は、最新のnightly(日々更新版)をビルドすることになります。ビルドされたイメージはすでに準備されているので、ビルドの必要はありませんが、そこは勉強です。単にビルドするだけなら資料がそろっているので何とかイケそうです。

  • 修正を公開する参加なら、Git 関連のコマンド(rebases やcherry-picks など)やGerrit ツール の知識が必要で、通常のプルリクエストは使わないみたい。コミュニティで開発されているので、管理者が集中して管理できるシステムみたいです。

  • Ubuntu のクロス環境でのビルドだとファイルシステムがext4 になるので、Haiku のファイル属性が保たれないらしく(xattr のサポートが必要)、XFS またはBtrfs のファイルシステムを準備するのがベターみたい。ちょっと面倒です。Haiku でHaiku をビルドするのが気楽で一番簡単です。

  • ビルドにはmake でなく、Jam (Perforce Jam のカスタムフォーク)が使われています。OS の開発にはよく使われているようです。開発環境としては進んでいますね。というか、知らないだけかな。

  • x86 (32 bit) をビルドするなら gcc7 とBeOS バイナリ互換のためのgcc2 が必要のようです。x86_64 (64 bit) をビルドするなら gcc7 だけなので、簡単な「x86_64」のビルドを選択。

Haiku をコンパイルする手順

(Haiku で、x86_64 をビルドする場合)

参考:


ゲストOS(Haiku) の設定

1-H-VM-setting.jpeg
→メモリは4GB、ディスクは10GB


ゲストOS(Haiku) の起動

2-H-Terminal.jpeg

→「Terminal」をメインに使います。コマンドを貼り付けたり、メッセージの記録に「StyledEdit」を使いました。


1. コンパイルに必要なツール

まずは、システムを最新にします:

~> pkgman refresh
~> pkgman update

すべてのプラットフォームで使うパッケージをインストール

~> pkgman install mtools python3 cmd:xorriso

→Haiku でビルドするときは、これだけで済みます。

Jam のバージョンを確認:

~> jam -v
Jam 2.5-haiku-20111222. OS=Haiku. Copyright 1993-2002 Christopher Seiwald.

→このバージョンが必要です。クロス環境のときは、jam 自体のビルドが必要になる場合があるみたい。


2. GitHub からHaiku のソースを取得

和訳と補足:

  • Haiku のソースコードは現在、コードレビューツール「Gerrit」が付いたGit ベースのリポジトリでホストされています。

  • 匿名でのやり方なら誰でも、Haiku のソースコードをダウンロードできます。

  • ただし、パッチを送信するには認証済み(貢献者とパッチ提出者)のやり方になり、指定方法が違います。

  • 「Haiku のビルド済みイメージには、ビルドツールがあらかじめインストールされています。Haiku 内からビルドする場合、ビルドツールは必要ありません。」と書かれています。これは「Jam」ツールのことみたいです。

  • コミット履歴を気にせず、ダウンロードを小さくしたい場合は、クローン作成時に「--depth 10」を付けると履歴を最後の10件のコミットに制限できます。

  • ダウンロードに時間がかかり、ホストOS がスクリーンセーバに落ちるとダウンロードからの更新で固まりました。ホストOS のスクリーンセーバ(設定→設定→電源管理→ブランクスクリーン: )を「5 分 → しない」に設定して、やり直しました。

  • Haiku にて、メニュー(青い葉)→Preferences →ScreenSaver →「一般」タブ→「スクリーンセーバーを有効にする」のチェックを外しました。

  • Haiku のソースをクローンするとき、サイズが大きすぎるのか、転送が開始されませんでした。

→「--depth 10」を付加して小さくすると開始しましたが、Updating files: 58% で止まります。
ごみ箱を空にして「--depth 5」でやり直したらOK になりました。

  • 作業用に「/boot/home/Git/」フォルダを作成しました。

  • それぞれのダウンロードが完了したら、一度、VM マネージャから立ち上げ直したほうがシステムが安定します。

→そのままだと、しばらくしてカーソルが消えたり、システムが不安定になりました。リソースがギリギリ?なのかも。

追記:

後でわかったことですが、もしかしたらUSB メモリが不調だったのかも…。


  • Build Tools:
~> cd /boot/home/Git/
ー> git clone --depth 5 https://review.haiku-os.org/buildtools

→と〜っても時間がかかります。

終わったら、しばらくしてから電源オフ。VM マネージャも閉じて、起動し直し。

  • Haiku:
~> cd /boot/home/Git/
ー> git clone --depth 5 https://review.haiku-os.org/haiku

→開始しなかったので、「--depth 5」でやり直すと開始しました(ファイルが破損していたことが後で判明)。

終わったら、しばらくしてから電源オフ。VM マネージャも閉じて、起動し直し。

追記:

  • 完了したら、「Git」フォルダを他のフォルダにコピーしてみます。それなりに時間はかかりますが、保存もできるし、後の作業に影響しないように、事前にファイルが正常に読み込めるかの確認になります。

3. 新規にビルドディレクトリを作成して、ビルドツールをコンパイル

まずは、システムを最新にします:

~> pkgman refresh
~> pkgman update

ビルドツールをコンパイル:

~> cd /boot/home/Git/haiku/
ー> mkdir generated.x86_64; cd generated.x86_64
ー> ../configure --build-cross-tools x86_64 ../../buildtools

→多量のメッセージが流れます。何度もチェックを繰り返しながらコンパイル、リンクなどが走ります。
リンク途中の libc++11convenience.a/ostream-inst.o のところで止まりました。起動メニューも開かない状態なので、リソース不足かな?。

VM メニューでリセット。VM マネージャも起動し直しました。
再起動後、Haiku-HD の詳細情報を見ると、容量10.00 Gib (5.97 GiB 使用中 -- 4.03 GiB 使用可能) です。
メモリ不足かな? シャットダウン後、設定変更。

システム
メインメモリー: 3072 MB →4096 MB
ストレージは変更できないみたい。

「generated.x86_64」フォルダを削除。ごみ箱を空にして、やり直しました。半日かかるつもりでいたほうが良いです。

追記:

  • 完了したら、「generated.x86_64」フォルダを別のフォルダに保存しておくと次のイメージの作成で失敗したときのやり直しが楽です。

4. 配布イメージをコンパイル

jam にて、CPUコア数の指定である「-j2」の数字を変更すると、ビルド時間を短く出来るみたいです。でも、自分のマシンのコア数は 2個なので、変更できません。

jam にて、「-q」は、エラーが発生したらすぐに終了させる指示で、エラーを発見しやすくするためのものです。
「-q」なしだと強引にコンパイルするらしいです。

ちなみに、動作を決めるターゲット名(@xxxx)は build/jam/DefaultBuildProfiles で定義されています。


  • nightly の「anyboot Haiku iso」イメージを作成

標準のビルドです。「ライブISO」が作成されます。
光ディスクに書き込むか、USB スティックに直接書き込むことができます。

~> cd /boot/home/Git/haiku/generated.x86_64/
ー> jam -q -j2 @nightly-anyboot

  • nightly の「raw ディスク」イメージを作成

Haiku の単純な「raw ディスク」イメージが生成されます。
VM で直接起動したり、USB スティックに直接書き込んだりできます。

~> cd /boot/home/Git/haiku/generated.x86_64/
ー> jam -q -j2 @nightly-raw

「anyboot Haiku iso」イメージの作成にて、惜しいかな、途中でエラーらしきメッセージが出た後に、
しばらくして、「Panic: vfs_read_pages() vfailed: Device timeout!」となりました。

9-H-build-Panic.jpeg

エラーしたのは、使用環境か、やり方か、ソースコードの問題か、I/O エラーだろうと思います。
たぶん、OS ビルドで使うには、メモリ8GB ではゲストもホストも4GB なので、ギリギリだとは思います。

  • 後でわかったことは、「Git」フォルダを保存するため他のフォルダにコピーしたら、「Haiku」フォルダの後半でエラーすることでした。ダウンロードの失敗でファイルが乱れているのか、USB メモリの不調と思われます。

  • ダウンロード(クローン)完了後に、退避(コピー)作業をすれば、それなりに時間はかかりますが、事前にファイルが正常に読み込めるかの確認になりそうです。

最後までやりたかったのですが、SSD でなく USB メモリをOS ビルドに使うと寿命を縮めるらしいので、ここで止めることにしました。目的とするOS ビルドの流れはつかめました。


まとめ

今回の作業でわかったこと。

  • ダウンロードがうまく行くか(うまく行ったかの確認)が鍵でした。

  • コマンドを実行すべき位置(パス)

  • メモリ8GB のマシンでVM でOS ビルドを実行するのはギリギリということ。リアルにHaiku で立ち上げて行うか、VM で行うなら16GBくらいが必要そう。

  • 時間がとてもかかるということ。
    事前にダウンロードだけは済ませておき、休日前の夜に早めにコンパイルを実行すると良いと思います。

「OS のビルドはとても時間がかかる」ことを理解しただけでも、良い体験になりました。だから、コミュニティで開発されているHaiku の公開が遅いわけです。

関係者とそのモチベーションに感謝。

([次の投稿に続く]
(https://qiita.com/FuRuYa7/items/f0b2d0c99dfd55debb1b))


今までの投稿一覧は 「ここ

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?