Can not build android_library with embedded so file (using ndk) #3924
Comments
|
command issued is also using local clang rather than one in android ndk. When I add android_binary it seems to cross that but gets stuck at some linking error (-lc++_static not found, even though libc++_static.a is referred directly too): |
|
@aj-michael who is doing most android changes. |
|
Thanks for response. I am using android-ndk-r14b/ I don't think this is include path related. Even the clang tool which is used seems to be wrong when going through android_library (using external/local_config_cc/wrapped_clang rather than external/android_ndk/ndk/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang). Note in bazelrc I am using --android_crosstool_top=@android_ndk//:toolchain-libcpp rather than blanket --crosstool_top=//external:android/crosstool. If I build through android_binary rather than android_library things work well. Also need to explicitly add lib path --linkopt=-Lexternal/android_ndk/ndk/sources/cxx-stl/llvm-libc++/libs/armeabi-v7a to build. (This is on top of include file workaround mentioned in #3923) |
|
The more typical way for an android app to depend on native code is to depend on a android_binary(
name = "and_bin",
srcs = glob([
"java/**/*.java",
]),
custom_package = "",
manifest = "AndroidManifest.xml",
deps = [
":native_deps",
"@android_sdk//com.android.support:support-annotations-25.3.1",
],
)
cc_library(
name = "native_deps",
srcs = [
"jni.cc",
],
)The reason that local clang was being used was that you were building the Basically, all you should need to do is use a If you still want to be able to build the See https://docs.bazel.build/versions/master/user-manual.html#flag--fat_apk_cpu |
|
Thanks Adam. I was expecting android_library to behave like android_binary in terms of changing cc_library's special treatment since what one can deduce from android_binary can be deduced from android library. My initial plan was to use bagel to produce the aar file which included so file (the model pieces) and use android studio project for UI pieces. Last paragraph will help with that. FWIW iOS_framework behaves similar to ios_application in terms of changing the cc_library to use ios_* settings. Given workarounds definitely sounds like lower priority. (Assuming the linking issues with libc++ will be addressed with the include issue). |
|
Hi Adam, Another question partially related to cross tool top. What is good way to detect bazel is building android. In protobuf lib I see: Which does not look compatible with using --android_crosstool_top. |
|
That's a hard question, because Bazel doesn't really know about "building android". When bazel analyzes cc_library rules, it uses the values of --crosstool_top and --cpu. When a Bazel analyzes an android_binary, it changes the values of --crosstool_top and --cpu based on --android_crosstool_top, --android_cpu and --fat_apk_cpu. Furthermore, while the Bazel team provides some built-in crosstools like //external:android/crosstool, there is nothing to stop a third_party from creating their own crosstool with a different name. Protobuf's config_setting looks like it should support your use case, if you are building an android_binary with --android_crosstool_top. Because the cc_librarys underneath it will see --crosstool_top set to --android_crosstool_top. |
|
It was not working because I am using --android_crosstool_top=@android_ndk//:toolchain-libcpp. I have to use that because grpc uses some cpp functions which are not in libstdcpp: https://stackoverflow.com/questions/22774009/android-ndk-stdto-string-support Adding: works. @xfxyjwf - Does adding this to protobuf BUILD sound reasonable? |
|
So just to summarize, the issue here is that "building for Android" can mean multiple things and it's not reasonable for protobuf team to keep an exhaustive list of all of them. (I'd argue it's also not reasonable for Bazel team to keep an exhaustive list, since users can define their own Android crosstools. But maybe that's another discussion.) @spinorx , you can try adding this to the bottom of your WORKSPACE: This will override the value of This solution is essentially "make the user specify that their crosstool is an android crosstool". |
|
Thanks Adam, this is much more elegant solution. |
|
FWIW, we have a long-term solution called "constraint-based platforms" that is still in the works. It should us to express things like, "this cross tool is usable for building against the Android platform". And the config settings can select on the well-defined "Android platform". You can read a bit about it here: https://docs.google.com/document/d/1-G-VPRLEj9VyfC6VrQBiR8To-dZjnBSQS66Y4nargGM |
jin
added
team-Android
jin
added
the
P3
|
Closing as Adam has provided a solution, and we are moving towards a new configurability solution. |
If possible, provide a minimal example to reproduce the problem:
Created a simple android_library which encloses java and needed so file at: https://github.com/spinorx/bazel_android_test
doing: bazel build --config android :and_lib -s
Getting compilation error:
I am trying to get android ndk to build so file using libc++ using bazel.
(Note that I has to push include under libcxx for libc++ because of:
#3923)
Environment info
Operating System:
Mac OS 10.12.6
Bazel version (output of
bazel info release):release 0.6.1-homebrew
Have you found anything relevant by searching the web?
(e.g. StackOverflow answers,
GitHub issues,
email threads on the
bazel-discussGoogle group)Anything else, information or logs or outputs that would be helpful?
(If they are large, please upload as attachment or provide link).
The text was updated successfully, but these errors were encountered: