pod install が成功しても、リンクは失敗する

新しいネイティブモジュールをひとつ追加しただけでした。

pod install は成功。117 の依存が解決され、Podfile.lock にもきちんと入っている。TypeScript のコンパイルも通る。

それでもビルドは止まりました。ld: symbol(s) not found for architecture arm64。

コンパイルは全部通っているのに、リンク段階で落ちる。

原因を突き止めようとして、まず躓いたのがログでした。ld: symbol(s) not found はただの要約行で、本当に必要なのはそのすぐ上に出る Undefined symbol: OBJC_CLASS$_XXX という行です。その名前さえ分かれば、どのフレームワークがリンクされていないか特定できる。

ところがコンソールにその行がありませんでした。

Xcode のビルドログを漁ることにして、DerivedData の Logs/Build に grep をかけた。何も出ない。理由は単純で、.xcactivitylog は gzip 圧縮ファイルです。拡張子だけ見てテキストだと思い込んでいました。

gunzip -c で展開して grep し直しても、やはり出ません。単純な gzip テキストではなく、独自のバイナリ構造を持っているようです。

結局、実際のシンボル名は最後まで確保できませんでした。

原因不明のまま Pods を丸ごと削除して入れ直したら、ビルドが通りました。ATT の許可ダイアログも正常に出て、その後の審査も通過しています。

ここで居心地が悪くなります。「消したら直った」は原因の特定ではありません。

このプロジェクトには、そもそも rm -rf Pods を禁じる規約を置いていました。143 個の pod を全部取り直して再コンパイルするのは、バージョンをひとつ上げるためにやることではない。その規約は実際うまく機能していました。

見落としていたのは、今回がバージョン変更ではなく新規モジュールの追加だったことです。禁止していたのは前者の話で、後者は最初から想定に入っていなかった。

規約を破ったのではなく、規約が想定していない状況に入っていた。この二つは違います。

原因が確定していないので、記事には推定であることを書きました。Pods フォルダと Podfile.lock のどちらの削除が決定的だったかも分離検証していません。expo-tracking-transparency 固有の現象なのかも未確認です。

再現を止めてしまったので、もう確かめられません。

次に同じところに来たら、まず yarn ios 2>&1 | tee でコンソールを丸ごとファイルに落とします。ログを掘るより、流れていく前に受け止めるほうが確実でした。

判定基準の整理と、無視してよい pod install の警告（spm.config.json の読み込み失敗、FirebaseCore の deprecation など）については、本体に書いています。

https://www.jacepark.com/pod-install-succeeded-but-link-failed/