Android NDKでcross compile 続き２
津路です。
前回では、armv7aをターゲットに指定して、iconvライブラリをコンパイルしたことを説明しました。
簡単にビルドは通ったのですが、実際に Android Studio のプロジェクトに組み込んで、
CMakeを利用してセットアップし、ビルドが通り、
実行すると、libiconv_openが見つからないというエラーに見舞われました。
シンボルは libiconv.soに見つかりますし、ヘッダにも宣言されていて、それを取り込んで、ライブラリの場所を
CMakeに知らせていますが、おかしいです。
iconvを使うライブラリのために、ディレクトリを作り、CMakeLists.txtも作成しました。
Java – JNIソース – ライブラリ – iconv
という階層です。
iconvをstaticにしてみたりしても同じでした。
そこで、iconvを手でビルドしたときのconfig.logを参照してみましたら、利用側のライブラリのconfigureがiconvをチェックするステップで、問題が起きていました。
iconvのlib_iconvが見つからないという記録があります。
ただ、その直後、この問題はスルーされて、iconvは使えると認識されています。
そして、-liconvを指定しても無視されて、iconvは外部ライブラリとしてビルドされています。
Androidプロジェクトでも、ライブラリのビルドは通りました。
と、Ubuntu側で調べてみると、iconvコマンドは、/usr/binにあり、iconv.hは/usr/includeに存在します。
実際に利用するライブラリをビルドしてみると、正しく認識されています。
ここでも時間を浪費するばかりですし、でかいライブラリやソースをプロジェクトに組み込むのを避けたいので、作っているAndroidプロジェクトはUTF-8前提なので、iconvは不要だときっぱり切って、ライブラリを、プロジェクト内でビルドしようと決めました。
さて、ライブラリの要となるソースを切り出さねばなりません。
問題は、外部のバイナリファイルからデータを読み込むコンポーネントがあり、どうしようかと調べてみました。
そのコンポーネントのソースを見ると、単に上部からパスを与えてやれば、動きそうな実装でした。
運がよかったというか、よく考えられて設計されています。
ライブラリはデータファイルの場所を示すテキストファイルを読み込んで、ユーザ設定を認識しているので、
そのテキストファイルをAssetフォルダに配置して、データファイルのパスを、native側に渡すこととしました。
さて、セットアップが通ったところで、うまく行くか心配しましたが、結構スムーズに動きました。