NDK17メモ
はじめに
いつも色々と教えて頂いてる serenegiant さんがNDK17の検証されていたので備忘メモ
Android Nとか O の64bit対応しようとするとNDKは上げざるを得ないんだよなー*1
動作環境
- Windows 10
- 8G
- AS 3.2-Canary16
- 3.2-alpha16
- gradle runtime 4.7
- ndk r13/r16/r17
動作検証編
serenegiantさんの検証一日目
2019年8月の64ビットバイナリサポート必須ってのは結構大変な事も多いぞい😰
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
libjpegturboリリース版は1.5.3、2.0ベータ1(1.5.90)がどちらも5/22にリリースされてた🤓
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
実質ビルドターゲットとしてはarmのv7aとv8aが最低限で可能ならx86とx86-64もっていう2通りしか選択肢はなくなるってことやね🤔
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
linsodium, libzmq, libczmq, cppzmq, libzyreはNDK17でビルドできた(libczmqとlibzyreはヘッドだとうまくいかんのんで古いコミットけど)😥
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
NDK16でarmeabi,armeabi-v7a,x86でビルドすると4.2MBだったのが、NDK17でarmeabi抜いてv8aとx86_64追加したら5.4MBになった😯
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
libjpeg-turboとlibpngもNDK17&stdc++で全ターゲットビルド出来た👍
libsodiumとlibzmqはビルド通ってるからそないまちごうてへんと思うんやけどなぁ🤔
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
armeabi-v7aとx86は正常に行くのにv8aだとlibczmqのビルド時にlibzmqが無いと言われて止まる🤔libzmqは正常にmake install走ってるのになぁ😵
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
libzmqとlibczmqとlibzyreとlibsodiumの件、ndk17だとarm64向けがlibczmqでコケる😢x86、x86_64、v7aは問題ない🤔
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
これからndk16に落として試す
ndk14まで落としてもだめってことはなんか根本的におかしいとこがあるんやな😫
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
ndk14b以前と15以後はヘッダー周りが大きく違う(unified headerになった)のが結構大きいのといくつかはそもそも無くなってしまった😫ただここらは全ターゲット共通なので頑張って書き換えるしかないんだけど今libzmqのarm64ターゲットだけビルド通らないのはプリプロセッサがarm64だけおかしいみたい😵
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
まじが～(^^;;
— close_yutori (@kimukou2628) 2018年5月30日
なんでarm64だけ修正？されてないんだろ～
使ってないからG様が直し忘れなオチ？
(win独自のファイルとかだと良くあるんですけどね
これtoolsの中とかWin対応だけ対応漏れ とかあったので*2
AS 3.x 以降で
— close_yutori (@kimukou2628) 2018年5月30日
NDK DSL & CMake 使うとtoolschainデフォルトでon っぽいですね
(C++ standard 構成
Expermental DSLの時は
toolschainのDSL記述例が別途あったのですが、、
あぁーそれだと同じところで引っかかるかもしれないですねぇ(｡･_･｡)とりあえず環境変数をいらってごまかしてプリプロセッサのところはクリアできたっぽいんですけど今度はundefined reference xxxの嵐に見舞われております(´・ω・`)arm64以外ではビルド通るので意味わからんです(泣)
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
細かい中身はいらないでし💦でもそういうパターンは個別にプレビルドしてヘッダーと共有ライブラリまたはスタティックライブラリとして配布＆参照するようにするのがいいんじゃないかなぁと思いますけど(｡･_･｡)その部分に直接関係ない人にまでビルドさせるのは無能というか責任範疇が不明確と
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
えっえっえっまっまっまっ待ってまっまっまさか1つのリポジトリの1つの(app)サブモジュールに全部突っ込んで何十人かで弄るなんて小学生真っ青なプロジェクト構成ではないですよね？元請けが機能毎というか各会社毎のリポジトリ作って他の会社は成果物のaarだけmavenリポジトリで参照するだけじゃ？
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) 2018年5月30日
これに関しては苦笑しかない
- Javaレイヤーの部分だけ切り出して開発してるのに
- 動作確認するためのフルビルドで30分
って正直時間の無駄だと思うんだよなーとは思いつつ。
普通aar提供するよなーとか
serenegiantさんの検証二日目
arm64ターゲットだけstdc++を指定しててもgnuc++11になってしまう😵
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) May 30, 2018
一日溶かしてちょっとは進歩したけど結局arm64のビルドだけは通らんかった(´・ω・｀)
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) May 30, 2018
明日は、もう今日だけど、別の仕事片付けてから再チャレンジするにゃ😼
<<メモ>>Android DevelopersのNDKのページ、日本語の方は色いろ抜けてるから英語のページで読むべし😥
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) May 31, 2018
これすごくあります・・・。翻訳追いついてないんだろうな・・・
同じセットアップでもarm64ターゲットだけlibc++_shared.soが見つからへんって言われる😰
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) May 31, 2018
いけたー＼(^o^)／＼(^o^)／＼(^o^)／
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) May 31, 2018
ndk16でarm64ターゲットのビルド通ったぞい✌
arm64のスタンドアロンツールチェーンがおかしい(少なくとも英語のAndroid Developersの記載内容と違う挙動する)のは確かだけど、実行時のオプション指定でクリアできそう🤔
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) May 31, 2018
リンカーオプションでc++_sharedを指定しなくて良いと書いてある。これはarm, x86, x86_64ターゲットに対しては正しいけどarm64ターゲットに対しては間違ってて明示的に-lc++_sharedを指定しないといけない。でもって明示的に指定してもarm,x86等のターゲットでも問題はないないので指定すべき
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) May 31, 2018
つまりarm64ターゲットのスタンドアローンツールチェーンのデフォルトオプション指定がどこかしらか他のターゲットと違うってことで、デフォルトだから指定しないじゃなくて必要なオプションは全て明示的に指定すべきってことであーる?
armeabiは無くしてarm v7a, arm64 v8a, x86, x86_64のビルドでけた✨
— さきちゃんの中の人、カピバラになりたい🐁 (@serenegiant) May 31, 2018
