Special Thx: テストにつきあってくれたboiled_sugar, Chikuzen両氏
解説は長くなるので折り畳み。
GPACを最新にしたところ、x264のconfigureでGPACを認識しなくなっていました。隠れていたので最初は気付かなかったんですけど、たまたま--disable-lavfを付けてx264のconfigureを走らせたところ、GPACが古すぎるぞこんちくしょーアップデートしろこのやろー、というwarningと共にGPACのサポートが外れてしまいました。こんな感じ。
[gist id=941726]
そもそもなぜlavfとGPACが関係するわけ…?意味わかんない…。
configureを覗いてみると、GPACの判定は以下のようになっています。
[gist id=941764]
この2回目(8行目の方)のcc_checkで何か問題が起きているみたいです。で、調べてみて原因がわかりました。ちなみに、このcc_checkというのは以下のようなもので、今回関わってくるのはLDFLAGSCLIという変数です。
[gist id=941766]
それでは原因の説明。
まずこんなコードがconfigureにはあります。
[gist id=941761]
このLDFLAGSCLIに何かを代入するのはこの場所が初めてです(configureを走らせる前にコマンドラインから直接設定した場合はもちろん除きます)。つまり、--disable-lavfでconfigureを走らせた場合は、LDFLAGSCLIにLAVF_LIBSの値は代入されません。じゃあこのLAVF_LIBSには何が入っているかというと、このコードより上にある、以下のコードを見ればわかります。
[gist id=941750]
ここまで絞ってから、リンカフラグを色々試行錯誤をしてみたら、どうも"-lz"がアヤシイことが判明。試しに--extra-ldflagsに-lzを追加してconfigureを走らせてみたら、きちんとGPACを認識しました。つまり
- GPAC側が更新によって-lzを要求するようになっていた
- lavfつきでビルドする際にLDFLAGSCLIに-lzが追加されていた
- LDFLAGSCLIに-lzがあるかないかでcc_checkでの判定に差が出ていた
ということでした。めでたし。んで、GPACを頻繁に更新している人がどれだけいるかは怪しいものですが(笑)、新しいGPACにしてもlavfありなしに関わらずきちんと判定できるように修正しました。ついでにちょいとCosmeticsもしてあります。
以上が解説です。あまり大きな修正でもないし、シンプルに。
それはそうと、GPACは覗けば覗くほど、呆れるというかなんというか…。L-SMASHがx264に取り込まれる日を妄想する毎日。`rm -fr GPAC`する用意はいつでもできている…(笑)
No comments:
Post a Comment