ndk + autotoolsの実験

年明け頃に作り出して、ずっと放置していたNDKのビルドサーバだけど、bridjでautotoolsベースのライブラリの実用にも目処が立った気がするので、掘り起こして動かしてみることにした。とはいえ、今回も掘り起こしたのを起動するにあたって、webサーバを更新したらmonoランタイムを更新させられるなど、VPSで毎回対応するには厳しいものがあり、なるべくならこのビルドサーバはnodeなどを使って書き直したいと思っている。

いずれにせよ、とりあえずは今動くものを使ってもう少しdogfoodingしようと思っている。今日は試しにlibiconvとgettextにパッチを当ててライブラリのみをビルドしてみた。(libiconv-1.13.1用パッチ, gettext-0.18.1.1用パッチ) 本当はさらにglibをビルドしたいのだけど、まだ上手くいっていない。glibそのものはAOSPに含まれているので、何かしらの修正を加えればビルド出来るはずだと思う。

未だにgccはよく分かっていないので、今日はいろいろ調べながらの試行錯誤だった。ひとつ解消したかったのは --nostdlib だ。これがあるせいで、crt0.oのリンクに失敗しないために--nostdlibが必要になり、そのせいで何かしらインクルードファイルなどが正しく取り込まれない問題が生じているような気がしている。crt0.oはmain()のローダーになるらしく、android環境用に短いgasソースで実現しているのをwebで探して発見したけど、利用条件も利用方法も不明だ。bionicにこれが含まれていないのは、gccが動かせなくなるからだろうか（gcc自身を動かすのに必要なのかもしれないという意味で）。

--nostdlibはnewlibというこれまた別の組み込み用libc実装を使う上でも使われるらしいけど、具体的な用法はよく分からない。

crt0.oが用意できてビルドの障害がひとつ取り除かれたとしても、ビルドされたバイナリは（armeabiの場合）arm環境でしか動作しないし、ビルド中はx86/64環境にいるので、ビルドされたツールは実行できないことになる。その意味では、dependencyというのは曖昧な概念だ、ということに気が付いた。たとえばgettextのツールがビルド中に必要になった場合、それはndkでビルドしたバイナリでは役に立たない（実行できないから）。この辺はAOSPを見れば切り分けが出来ているのかもしれない。

bionicはpthreadのcancelやiconv相当の機能を提供しないようなので、ビルドでハマるものは他にも数多くありそうだ。