ログは「Error 1」だけだった。rpg450→451、1分45秒の修正

GBDK開発発掘記 / エラー文が薄いとき、source diffからどこまで言ってよいか

rpg225は親切でした。関数名まで出して「already has body」と教えてくれました。

rpg450は違います。調査用抜粋に残っている実エラーは、たった一行です。

make: *** [Makefile:35: fast] Error 1

これだけでは、何が壊れたのか分かりません。

失敗jobは 20260530_002005_2c841d5b。次の成功jobは 20260530_002150_31b0844b。job IDの時刻差は1分45秒です。

ログだけでは原因を決められない

エラー分類はMAKE_BUILD_FAILURE。Bank overflowのような警告も、duplicate definitionのような関数名も、この抜粋にはありません。

ここで「rpg450はリンクエラーだった」と言い切るのは危険です。成功版のtarget名に link_fix と入り、source diffにもそれらしい修正があるため手がかりにはなりますが、失敗ログそのものが具体的なlinker errorを示しているわけではありません。

発掘記事では、こういうときに「分からない部分」を残します。

成功側ではinventory.cにhelperが追加されていた

rpg450→451の実diffでは、inventory.c が +9 / -0 です。成功側に次のfile-scope helperが追加されています。

static void inventory_audio_pump(void) {

    /* rpg451:

     * File-scope helper for rpg450 BGM continuity.

抜粋は関数全体を載せていないため、helperの完全な処理内容まではここから断定しません。ただし、rpg451でinventory.cにこのhelperが追加されたことは確認できます。

target名も手がかりになる

MakefileのOUT名は、rpg450_menu_bgm_continuous_update.gbc から rpg451_inventory_audio_pump_link_fix.gbc へ変わっています。

名前からは、rpg450でメニュー中のBGM継続更新を触り、rpg451でinventory側のaudio pumpに関するlink fixを行った意図が読み取れます。

ただし、target名は開発者が付けた作業ラベルです。名前だけで「これが唯一の原因だった」とは扱いません。

事実・手がかり・断定禁止を分ける

この事件は、発掘記事の書き方そのものを説明する題材になります。

確認できる事実は、rpg450がfailed、rpg451がsuccess、成功側inventory.cにhelperが追加、MakefileのOUT名が変わったことです。

手がかりは、helper名が inventory_audio_pump、コメントに BGM continuity、target名に link_fix が入っていることです。

一方、この抜粋だけでは、具体的にどのsymbolが未解決だったのか、helper追加だけが唯一の修正要因だったのかまでは確認できません。

この3段階を分けておけば、後から元build.logやsource ZIP全体が見つかったときに、記事を安全にアップデートできます。

「短いログ」も捨てない

make Error 1だけを見ると、保存価値が薄く見えます。でも次の成功jobとsource snapshotが残っていれば、比較材料になります。

今回も、失敗ログ単体ではほとんど語れませんが、1分45秒後の成功sourceと並べることで、inventory.cに何が追加されたかを確認できました。

完成版だけを保存していたら、「rpg450で一度失敗した」という事実自体が消えます。

historical ROM画面は使わない

rpg450はbuild failedです。また、この調査用抜粋だけではrpg451のhistorical ROM実体が現在救出済みかまでは分かりません。

したがってこの記事の3枚は、job情報、実source diff、証拠の読み分けを図示した技術画像です。実ROM画面ではありません。

今なら、エラー分類にconfidenceも持たせる

今この発掘DBをさらに強くするなら、error classificationだけでなく根拠の強さも持たせます。

例えば、ログに明示的なduplicate definitionがあればconfidenceは高い。今回のようにログがError 1だけで、target名と次jobのdiffから修正意図を読む場合は、原因推定のconfidenceを低めにしておきます。

そうすれば、後から記事生成するときも「事実」と「推定」を自動で混ぜにくくなります。

次は、またBank overflowへ戻すのではなく別の事故を探す

このアーカイブには、syntax errorやlink error系の別チェーンも残っています。次は、ログに具体的なsymbolや文法箇所が出ているものを優先して拾い、A081のように初心者でも追いやすい小さな失敗記事を増やします。

一次資料メモ

rpg450 failed job: 20260530_002005_2c841d5b

rpg451 success job: 20260530_002150_31b0844b

分類: MAKE_BUILD_FAILURE

実エラー: make: *** [Makefile:35: fast] Error 1

inventory.c diff: +9 / -0

成功側追加: static void inventory_audio_pump(void)

ソースコメント: File-scope helper for rpg450 BGM continuity

Makefile OUT: rpg450_menu_bgm_continuous_update.gbc → rpg451_inventory_audio_pump_link_fix.gbc

図版: 実job情報・実source diff・証拠境界の解説図。実ROM画面ではない

編集状態: 初稿 / Technical Review前