気の向くままに辿るIT/ICT/IoT
システム開発

NetBSDのビルドとbuild.sh

ホーム前へ次へ
NetBSDのインストールと運用/NetBSD/i386 6.1.x編

NetBSDのビルドとbuild.sh

NetBSDのビルドとbuild.sh

2016/11/30

 NetBSDは、同一アーキテクチャ上でのネイティブコンパイルだけでなく、他のアーキテクチャや異なるOS上でツール構築、カーネル・ユーザーランド・リリース・CD用インストールISOディスクイメージ・USBメモリ用インストールイメージ・Liveイメージ(USBメモリ用とQEMUなどに使えるHDD版)などのビルド(make)ができる、いわゆるクロスコンパイリング(クロスコンパイル)が可能でNetBSDには、これらを行なうにあたり、build.shという、より手軽で便利なシェルスクリプトがあります。

 例えば、他に類を見ないほど様々なアーキテクチャに対応していることも特徴の1つであるNetBSDにおいて、組み込み用やリソースの限られるアーキテクチャ用のビルドをよりリソースが豊富なアーキテクチャや仮にNetBSDマシンがなくても他のOS上でクロスビルドできることは、それらの制約を取り払い、大幅な時間の節約にもなる為、有用です。

NetBSDをビルドする為の準備

 これらを行なう為には、元となるソースコードが必要となり、NetBSDの場合、HTTPやFTPからtarballをダウンロードしたり、CVSからソースをチェックアウトしたりすることで取得することができます。

ソースコードの圧縮ファイル類があるリポジトリ上のパス

(一例)
$ ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-7.0.2/source/sets
$

 FTP/HTTPリポジトリでかつ、release版の場合、ソースのセットは、本家やミラーサイトのpub/NetBSD/NetBSD-`uname -r`/source/setsというパス以下に置かれることになっています。

 ビルドするにあたっては、(実際には、Xが不要ならxsrc.tgzは不要ですが、)基本的に、そこにある.tgz(tar.gz)ファイルを全てダウンロード、ローカルの任意のパスにそれらtarballを全て展開します。

ソースコードを展開するパス

(一例)
$ sudo mkdir /usr/src/NetBSD7.0.2
$

 展開するパスは、/usr/srcが用いられることも多いですが、更に浅いまたは、深い階層でも、はたまたホームディレクトリ内でも構いません。

 何れにしてもbuild.shには、必要都度、自動的にsuしてくれる-Uオプションがあり、これを使う前提でビルド作業は、一般ユーザーアカウントで行なうべきとされています。

(一例)
$ sudo chown user_account /usr/src/NetBSD7.0.2
$

 一般ユーザーアカウントを使うということは、つまり、どこに展開するにせよ、展開先のディレクトリの所有者(、必要なら所有グループも)は一般アカウントのものである必要があり、そうでない場合には、chownしておく必要があります。

必読リソース

(一例)
$ cd /usr/src/NetBSD7.0.2/usr/src
$ ls
BUILDING UPDATING build.sh ...
$ ./build.sh -h | less
...
$ less BUILDING
...
$ less UPDATING
...
$ less build.sh
...
$

 build.shは、tarballを展開後のusr/srcディレクトリにあり、実際にビルドする前にusr/src/build.sh -h、usr/src/BUILDING(、usr/src/UPDATING)、usr/src/share/mk/bsd.READMEには目を通しておくのが賢明です。

 もちろんbuils.shスクリプト自体や先のリンク先"Part V. Building the system"ももちろん重要な情報源です。

NetBSDのビルド

(一例)
$ cd /usr/src/NetBSD7.0.2/usr/src
$ ./build.sh -U -O ../obj ...

 build.shには、オプションや参照される環境変数がたくさんあるので詳細は先の各種リソースに譲りますが、一般ユーザーアカウントで実行するにあたり[-U]は最低限、BUILDINGを読むとMAKEOBJDIRの特定は複雑さを伴い失敗の可能性もないとは言えない為、MAKEOBJDIRやこれを意味するコマンドラインオプション-O(または、MAKEOBJDIRPREFIXかこれを意味する-M)は指定しておくのが賢明とあるので、一部[-U]オプションすらも要らないケースもあるでしょうが、[./build.sh -U -O obj_path]/[./build.sh -U -M obj_path]をベースにすることになるでしょう。

(クロスコンパイル時はアーキテクチャ指定も必須)
$ ./build.sh -U -O ../obj -m armv7 ...

 また、自ホスト用、ビルドマシンと同一アーキテクチャ用のビルドでは省略可能ですが、クロスコンパイルする際には、-mオプション(とその引数としてビルド対象となるアーキテクチャの指定)も必要となります 。

build.shのターゲット一例

 build.shには、必要に応じたオプションと(makeターゲットであり、)ツールチェーンである[tools]、カーネルである[kernel=conf]、配布物一式(カーネル以外のユーザーランド)である[distribution]、リリース配布物である[release]、インストールCD用イメージである[iso-image]、インストールUSB用イメージ[install-image]、インストール済みNetBSDのライブイメージである[live-image]。。。等々といったターゲットを1つ、または、適切な組み合わせと順番で複数指定し、実行することができます。

 これらの内、[live-image]ターゲットについては、比較的最近利用できるようになったようです。

ビルドにtoolsは必須

(一例)
$ ./build.sh -U -O ../obj tools
$

 ビルドするに当たっては、NetBSDは、Cで書かれており、ツール群のなかには、C++も使われているのでgcc/g++といったコンパイラ、リンカ、アセンブラ...etc.(gnusrc.tgz)が必要となる為、開発用ツール群(ツールチェーン)である[tools]は必須となります(toolsターゲットを単独で、併記するなら他のターゲットに先立って指定することで、あらかじめビルドしておく必要があります)。

(一例)
$ ./build.sh -U -O ../obj tools
$ ./build.sh -U -O ../obj release
$

 ただし、[release]をビルドする場合には、[tools]も併せてビルドされるので[tools]を事前にビルドしておく必要はありません。

カーネルのビルド

(一例)
$ ./build.sh -U -O ../obj tools
$ ./build.sh -U -O ../obj kernel=conf
or
$ ./build.sh -U -O ../obj tools kernel=conf
$

 カーネルのビルドには、[kernel=conf]ターゲットを使いますが、事前に[tools]が必要なので併記するなら[tools]を先に、そうでない場合は、あらかじめビルドしておく必要があります。

 尚、[conf]は、各種カーネルオプションを記述する構成ファイルであり、カスタマイズするなら、例えばGENERICなど既存のカーネル構成ファイルをコピーして編集、指定するのが無難でしょう。

(一例)
$ pwd
/usr/src/NetBSD7.0.2/usr/src
$ ls sys/arch/i386/conf
...
$

 既存のカーネル構成ファイルパスは、[usr/src/sys/arch/i386/conf]です。(i386の部分には、当然、必要なアーキテクチャを指定します。)

 構成・構築したカーネルは、稼働中のシステム上の既存のカーネルと単に置き換え、マシンを再起動することでアップデートすることができますが、うまく起動しない場合に備え、念の為、古いカーネルはリネームするなどして残しておくとよいでしょう。

ユーザーランドのビルド

 カーネル以外のユーザーランド(配布物一式)をビルドするには、[distribution]ターゲットを使います。

(一例)
$ ./build.sh -U -O ../obj distribution
$ ./build.sh -U -O ../obj install=/
or
$ ./build.sh -U -O ../obj distribution install=/
$

 [distribution]をあらかじめビルドしておき、新ためてbuild.shに[install=/]ターゲットを渡すか、これを先に指定して[install=/]と併記することで構築した[distribution]をインストールすることができます。

 全く同一バージョンのユーザーランドをビルドしてインストールするということは普通ないと思われ、新しいバージョンのユーザーランドを構築する場合には、カーネルも同じく新しいバージョンでないと不整合が起こる可能性がある為、古いユーザーランドへの互換性を持つはずの新しいカーネルを先に入れ替え、様子を見るなりしてからユーザーランドをインストールすることになるはずなので既にビルドしているでしょうから言うまでもありませんが、[distribution]のビルドにあたっては、それ以前にカーネル、更にそれ以前に当然、[tools]がビルドされている必要があります。

インストールイメージやライブイメージのビルド

(一例)
$ ./build.sh -U -O ../obj release
$ ./build.sh -U -O ../obj install-image
or
$ ./build.sh -U -O ../obj release live-image
$

 [iso-image]、[install-image]、[live-image]については、事前に[release]をビルドしておくか、併記する場合、[release]を先に指定しておく必要があります。

 何れにせよ、一度、[release]をビルドすれば、これらターゲットを単独で指定することができます。

 ただし、[iso-image]については、検証時点において[release]をビルドすれば、敢えてターゲット指定するまでもなく生成されていました。

build.shとXウィンドウシステム

 build.shで[distribution]や[release]をビルドするにあたり、デフォルトでは、Xウィンドウシステムは含まれていません。

 よって、もし、Xが必要なら、あらかじめ[MKX11=yes]としておくか、これに相当するコマンドラインオプション[-x]を付けます。

 尚、アーキテクチャによってデフォルトは異なり、詳細はBUILDINGに譲るとして少なくともi386やamd64などでは、Xorg、一部アーキテクチャでは、XFree86ですが、これは、X11FLAVOUR=Xorg|XFree86(いずれか)を設定することによって変更することが可能となっています。

build.shはマルチコアCPU対応

 build.shは、マルチコアCPUに対応しており、コマンドラインオプション[-j n]のnに実際のコア(スレッド)数と同一か、プラス1、もしくは、2倍の値までは一般にうまく機能するとされています。

 ちなみにシングルコアCPUに-jオプションを指定すると異様に遅くなったり、予期せぬ結果となることもあるのでシングルコアの場合は、[-j]オプションを付与しないよう注意が必要です。

 尚、BUILDINGによれば、以前は、NBUILDJOBSがこれに相当する環境変数として存在していたようですが、廃止された為、現在は、-jオプション一択とのことです。(build.shにおいては、MAKE_JOBSは、そもそも使えないので注意。)

NetBSDのビルド所要時間

 デュアルコアマシンもありましたが、今回の検証には、その場の勢いでなぜか、シングルコアIntel Celeron M 520 1.6GHz/RAM 2GB/NetBSD 7.0.1を使用したところ、[release]に約3時間、[live-image]に約25分程度かかりましたが、[iso-image]/[install-image]は一瞬(数分かかったかかからないか)程度でした。

 前述の通り、[release]と[live-image]も、この順に併記して実行することも可能です。

ホーム前へ次へ