[[diary/Kojima]]

・buildroot

Plamo のインストーラで使っている busybox がだいぶ古くなってきたので,新しいバージョンを使ってみようと
buildroot システムに挑戦.

busybox の場合,uClibc というコンパクトな libc と組み合わせて使うことが多いのだけど,
システム標準の glibc ではなく uClibc を使うためには,まず uClibc を gcc でビルドして,
その uClibc を使うように gcc をビルドし,その gcc を使って busybox 等のソフトウェアを
ビルドしていく,という手間がかかる作業が必要になる.

昔の busybox ではこういう風に構築した開発環境一式を loopback 
でマウントして使えるようなファイルシステムイメージを提供してくれてたのだけど,
最近(といっても一年以上前だが)では上記の手順を自動的に実行するようなスクリプト群が
提供されるようになっていて,それを使って自力で環境を構築するようになっている.

この仕組みを buildroot と呼んでいるのだけど,
スクリプトを使って必要なソフトウェアを自動的に取ってきては configure を走らせてビルドしたり,
そのうちの必要な部分のみをファイルシステムイメージ用のディレクトリにコピーしてくれたり,
最終的には loopback でマウントできるファイルシステムイメージにまとめてくれたり,
とすごく高機能なんだけど、
ただあまりに高機能すぎて,仕組みの細部が分らなくて微調整が効かないといった弊害も存在したり.

今回も,とりあえずデフォルトの設定でビルドするのはそれほど苦労しなかったのだけど,
そこからいくつかインストーラに必要なソフトウェア(mke2fsとか udev とか)を追加しようとすると
結構とまどうことが多かったり.

ついつい Linux のカーネルみたいに make menuconfig の画面で新しく追加した機能は自動的にチェックされて,
ライブラリ等も再ビルドが必要な場合は自動的に再ビルドルされるのかと思ってたけど,
どうも uClibc に影響するような変更(例えば 2GB 以上のファイルをサポートする機能とか)を変更するためには,
uClibc を明示的に make clean して再ビルドしてやらないといけないみたい.
まぁ,考えてみれば Linux カーネルみたいに,全体が統合されたソフトウェアではなく,
ライブラリやコンパイラといった独立したソフトウェアの集合体だから,
それぞれの間の設定情報のやりとりなんかも限界があるのは分かるのだけど,
「なぜ lseek64 が undefined になるんだ?」とか
「なぜ dialog が ncurses のヘッダーを見ない?」みたいなトラブルでずいぶん悪戦苦闘中.
make distclean とかすると,ダウンロードしたソースコードまで削除されちゃうしなぁ..(涙
-busyboxの機能が大きくなってきてそちらに注力されているようでPlamoではあたりまえのユーティリティが使えなくなっています。場合によってはdeli linuxまたはfloppyfwのDevelopment kit利用も手かなと思っています。 -- [[名倉]] &new{2008-04-15 (火) 09:01:15};


#comment

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS