App Builder ビルドが失敗した場合: ログを読んで原因を見つけ、再度ビルドします。

App Builder のアプリは、レシピからプログラムを 1 つずつ順にビルドします。そのうちの 1 つが失敗することがあります。このガイドでは、テスト用 NAS で実際に起きた失敗を追います。70 個のレシピから成るアプリ TurboShell のビルドが、7 番目のレシピである Korn シェル ksh93 で止まりました。

どこ失敗したレシピ
ログ最後の行
原因エラーの名前
変更修正済みレシピまたはアプリ
再ビルド成功したレシピを再利用

画像は、Bucket & Code Server IDE 1.0.0-49 で、修正の前と後に撮影したものです。

01失敗した場所

ビルドが失敗しても、アプリは元のままです。以前に成功したビルドがあれば、有効化、ダウンロード、QPKG としてエクスポート は引き続きそのビルドを使います。サイドバーでは最新のビルドに失敗と表示され、アプリのページのパイプラインにも失敗が表示されます。

ビルド順序 カードには、失敗したレシピと、失敗した段階が表示されます。この例では、それより前のレシピはすべて合格、後のレシピは 未到達 と表示され、以前のビルドのログが残っています。

ビルド順序カード: 最後のビルドは失敗、メッセージ builder: FAILED ksh93 in build (exit 1)、レシピ 1～6 は合格、ksh93 はコンパイル中に失敗、fish は未到達 (以前のログあり)

02レシピのログを読む

レシピの行のログを押すと、ビルダーがそのレシピについて書き出した内容 (各段階、コンパイラーの出力、監査、チェック) が開きます。原因は終わりのほうにあります。

ksh93 のログ: libast の misc/magic.c で error: unknown type name Magic_t; did you mean magic_t、続いて magic.o の作成中に mamake の終了コード 1、最後に package: make failed

ビルドジョブ自体のログ (下部パネル (Ctrl+J) の ジョブ の下) も、同じ行で終わります。ビルダーが、レシピのログの最後の 40 行をそこにコピーするためです。
失敗したレシピのビルドツリーは、アプリの次のビルドまで、アプリのビルドフォルダー (データフォルダーの apps/<app>/build/work/<recipe>) に残ります。エディターのターミナルでそこを開くと、ソースと生成されたファイルを確認できます。

03原因を見つける

コンパイラーは ksh 独自の型 Magic_t を探し、代わりに、file コマンドのライブラリである libmagic の型 magic_t を提案しています。つまり、ksh のソースにある #include <magic.h> が、ksh のヘッダーではなく libmagic のヘッダーを読み込んでいました。

TurboShell はレシピ file もビルドし、このレシピが libmagic の magic.h をアプリのプレフィックスにインストールします。どのレシピも、そのプレフィックスの include フォルダーを検索パスに入れてビルドされます。そのため、各プログラムは、自分より前にビルドされたライブラリを見つけられます。TurboShell の最初のビルドでは、ksh93 が file より先にビルドされ、成功しました。2 回目以降のビルドは、最後に成功したビルドのコピーの中で行われます。そのプレフィックスにはすでに libmagic のヘッダーがあり、ksh93 がそれを読み込みました。

このエラーのように、エラーが何かの名前を挙げているときは、その名前をソース、前のレシピ、ビルド環境とさかのぼって追います。ログからわかるのは、このビルドがどこで止まったかです。どう変更すれば直るかまでは、ログには書かれていません。

04変更できるもの

修正済みのレシピ。 レシピは、パッケージのリリースとリリースの間にも、署名付きのカタログとして NAS に届きます。アプリ ページの レシピライブラリ カードには、ビルドが使っているレシピと、最後に確認した日時が表示されます。レシピの更新を確認 を押すと、すぐに確認します。この例では、修正済みの ksh93 レシピがカタログ 2026.10.08-1 で届きました。このレシピは、ksh93 がプレフィックスのヘッダーを読み込まないようにします。
アプリ。 アプリのページの変更でレシピの追加と削除、環境とリンクモードの設定ができます。別のレシピと競合するプログラムは、独立したアプリとしてビルドできます。
環境。 レシピが、環境にない新しいコンパイラーやビルドツールを必要とする場合は、変更で別の環境を選びます。

05レシピのソースを自分で変える

修正済みのレシピがまだ届いていないときや、ライブラリのレシピがビルドするものより新しいリリースがプログラムにあるときは、レシピのコピーで新しいソースを指定できます。コピーは、自分のどれかのプロジェクトの recipes/ フォルダーに置きます。そのプロジェクトのレシピを使うアプリは、ライブラリのレシピの代わりにコピーをビルドします。ライブラリとほかのアプリはそのままです。Bucket & Code Server IDE 1.0.0-55 のライブラリでは tmux のレシピが 3.7c をビルドし、ここでのコピーは 3.8 をビルドします。

ビルドジョブのログは、recipe library: の行で使用中のライブラリを示します。パッケージ自身のライブラリは /usr/bin/bucketvs/share/bucketvs/recipes/、カタログのライブラリはデータフォルダーの recipes/current/library/ です。エディターのターミナルでプロジェクトのフォルダーに移り、そこからレシピのフォルダーをコピーして、新しいアーカイブの sha256 を求めます。

mkdir -p recipes
cp -r /usr/bin/bucketvs/share/bucketvs/recipes/tmux recipes/
curl -fsSL https://github.com/tmux/tmux/releases/download/3.8/tmux-3.8.tar.gz | sha256sum
e79c699c7e949dccd0a4a125e17b8d1261e311b16979dbc8eb34542f3966d82e  -

recipes/tmux/recipe.json では、バージョン、アドレス、sha256 の 3 つの値が変わります。

"version": "3.8",
"source": {
  "url": "https://github.com/tmux/tmux/releases/download/3.8/tmux-3.8.tar.gz",
  "sha256": "e79c699c7e949dccd0a4a125e17b8d1261e311b16979dbc8eb34542f3966d82e"
},

ファイルを保存するとプロジェクトのレシピが検査され、結果がエディターの問題ビューに一覧表示されます。bvs recipe lint . はターミナルで同じ検査を行います。プロジェクトビューの レシピ カードでは、コピーに ライブラリの 3.7c を置き換えます と表示されます。問題のあるコピーは除外され、ライブラリのレシピが代わりに使われることはありません。tmux を必要とするビルドは、開始前に理由を示して止まります。
アプリのページでは、レシピを持つプロジェクトが 1 つでもあれば、変更に プロジェクトのレシピ が表示されます。プロジェクトを選び、変更を保存 を押してから 再ビルド を押します。ビルドジョブのログには、プロジェクトから読み込んだレシピが並び、tmux replaces the library's tmux 3.7c in this app と出ます。
同じ方法でビルドできるリリースなら、この 3 つの値だけで足ります。別の configure オプションやパッチが必要なら build.sh も変更します。このファイルについてははじめての自作レシピで説明しています。
コピーはバージョンに関係なく、名前でライブラリのレシピを置き換えます。ライブラリのレシピがコピーより新しくなっても、アプリはコピーをビルドし続けます。プロジェクトのレシピ を なし：ライブラリのみ に戻すか、コピーを削除してください。

06再ビルド

アプリのページで 再ビルド を押すと、新しいビルドジョブが始まります。失敗したビルドの後でアプリのファイルが変わっていなければ、そのビルドが止まったところから再開します。失敗したビルドで完了していたレシピは再利用され、失敗したレシピがもう一度ビルドされます。ここでは、カタログの修正済みレシピで ksh93 がビルドされます。

07ビルドは成功したがプログラムが起動しない場合

どのビルドも、アプリを置き換える前に結果を確認します。確認は 2 つで、各レシピ自身のチェックと、すべてのプログラムとライブラリを実行せずに読み取る分析です。アプリの 依存関係 タブには、この分析で見つかったものが並びます。見つからないライブラリ、ライブラリが定義していないバージョン、アプリの外を指す RUNPATH、アプリの対象より新しい glibc を必要とするプログラムなどです。対応している検出結果には、パネルが推奨する対処を示します。多くはボタンになっています: … を追加してビルド、… に切り替えてビルド、RUNPATH を修正、別の環境を選ぶ、この NAS 専用でビルド。NAS 上では、bvs deps <app> で同じ一覧を表示できます。