Does this project support bazel 5.2.0? about rules_android_ndk HOT 19 CLOSED

Hi, it looks like you're using the "native" version (i.e. the non-Starlark version) of android_ndk_repository (https://bazel.build/reference/be/android#android_ndk_repository)

Are you loading the rules_android_ndk version (i.e. Starlark version) of android_ndk_repository like this in your workspace file?:
https://github.com/bazelbuild/rules_android_ndk#getting-started

from rules_android_ndk.

Thanks for reply.
What's the difference between WORKSPACE in your second url and WORKSPACE in examples/basic ?
I've add the https://github.com/bazelbuild/rules_android_ndk#getting-started in the end of my project WORKSPACE, while
another error happend:

ERROR: /home/zhu/.cache/bazel/_bazel_zhu/bf5ae187c183939636c65d4e920e7dc3/external/local_config_cc/BUILD:47:19: in cc_toolchain_suite rule @local_config_cc//:toolchain: cc_toolchain_suite '@local_config_cc//:toolchain' does not contain a toolchain for cpu 'arm64-v8a'
ERROR: /home/zhu/.cache/bazel/_bazel_zhu/bf5ae187c183939636c65d4e920e7dc3/external/local_config_cc/BUILD:47:19: Analysis of target '@local_config_cc//:toolchain' failed

I am compiling a so for Android App, and My compile command is

bazel build -c opt --config=android_arm64 avatar-sdk/Session:libsession.so --fat_apk_cpu=arm64-v8a --android_crosstool_top=@androidndk//:toolchain

By the way, I have compiled my project well by bazel with ndk r21.
Thanks again.

from rules_android_ndk.

Ah, so is avatar-sdk/Session:libsession.so a cc_binary? If so, then other flags are needed, because only android_binary will use --fat_apk_cpu and --android_crosstool_top. You'll need to set --cpu and --crosstool_top (and maybe also set --host_crosstool_top to the default host toolchain). Is that was --config=android_arm64 does?

from rules_android_ndk.

Yes, avatar-sdk/Session:libsession.so is a cc_binary.
And my project (mediapipe written by google) .bazelrc is as following:

# Android configs.
# Note: the documentation tells us to use @androidndk//:default_crosstool, but
# the automatic configuration transition uses //external:android/crosstool.
# Using it here works and spares us from having two different config_settings
# for Android.
build:android --crosstool_top=//external:android/crosstool
build:android --host_crosstool_top=@bazel_tools//tools/cpp:toolchain
build:android --linkopt=-landroid
build:android --linkopt=-ldl
build:android --linkopt=-llog
build:android --linkopt=-lm
build:android --linkopt=-Wl,--gc-sections

build:android_arm --config=android
build:android_arm --cpu=armeabi-v7a
build:android_arm --fat_apk_cpu=armeabi-v7a

build:android_arm64 --config=android
build:android_arm64 --cpu=arm64-v8a
build:android_arm64 --fat_apk_cpu=arm64-v8a

So，your guess is exactly right.
I guess that some options(which toolchain is to be selected?) are also from my project(mediapipe) but not from the rules_android_ndk.
In other words, rules_android_ndk doesn't work as expected.
Thanks.

from rules_android_ndk.

So it looks like the problem is:

build:android --crosstool_top=//external:android/crosstool

that's using the label from the "native" android_ndk_repository rule.

This would use the one from the starlark version:

build:android --crosstool_top=@androidndk//:toolchain

however it looks like there are a few config_settings in mediapipe that use the label from the native version:

https://github.com/google/mediapipe/blob/7fb37c80e88495d6b50f39a9e9d348e2c0796a2c/mediapipe/BUILD#L20-L69

https://github.com/google/mediapipe/blob/5b90afda701d1ddb91a435f064507b43636ea966/mediapipe/framework/BUILD#L157-L162

So those might cause other problems -- you could try temporarily changing those config_settings to use @androidndk//:toolchain to see if that works around any issues you find with --crosstool_top=@androidndk//:toolchain, and then issues probably need to be opened with mediapipe to work through them.

from rules_android_ndk.

Thanks for reply.
I've tried all your suggestions and it also be in error.
The error is:

ERROR: /home/zhu/mediapipe/mediapipe/util/BUILD:77:11: no such target '@androidndk//:cpufeatures': target 'cpufeatures' not declared in package '' defined by /home/zhu/.cache/bazel/_bazel_zhu/bf5ae187c183939636c65d4e920e7dc3/external/androidndk/BUILD and referenced by '//mediapipe/util:cpu_util'

I have compiled an simple sample from https://bazel.build/reference/be/android?hl=en#android_ndk_repository_cpufeatures
but the error no such target '@androidndk//:cpufeatures' existed.
Any suggestion will be help.
Thanks again.

from rules_android_ndk.

The cpufeatures target that the native version of android_ndk_library was not added to the starlark version.
I added them with b718a4b and c76a94f.

However, in the native version of android_ndk_library, the cpu features files would be included like
#include "ndk/sources/android/cpufeatures/cpu-features.h", and with the way that the starlark ndk respository is laid out, it would be #include "sources/android/cpufeatures/cpu-features.h" in the starlark version. So mediapipe might not compile with the file path without the ndk/ prefix. If it's possible to modify your local version of mediapipe temporarily, you could try that. If not, then mediapipe will need to be updated.

from rules_android_ndk.

Looking through mediapipe's code with respect to my previous comment, and yeah, this import will fail with the starlark version of android_ndk_repository:

https://github.com/google/mediapipe/blob/6cdc6443b6a7ed662744e2a2ce2d58d9c83e6d6f/mediapipe/util/cpu_util.cc#L20

Probably the most straight forward thing to do would be to somehow make the starlark version of android_ndk_repository backwards compatible with the ndk/ prefixed import paths...

from rules_android_ndk.

Thanks for reply. @ahumesky
I have changed WORKSPACE to follow your latest commit c76a94f. The no such target '@androidndk//:cpufeatures' has gone. Thanks for your work.
As you mentioned, the #include "ndk/sources/android/cpufeatures/cpu-features.h in Mediapipe need to be changed to #include "sources/android/cpufeatures/cpu-features.h".
After these changes, everything is ok in compilation step. however, linker complained about it as following:

ld.lld: error: unable to find library -lpthread

I find that #5 (comment) in point (6) and bazelbuild/bazel#7983 have mentioned the similar problem. I have modified some configs following gflags/gflags@59fb644 , but failed again.
My bzl files of libraries in external directory are

Any suggestion will be help.
Thanks again.

from rules_android_ndk.

With 44dcd01 changing the include path in mediapipe shouldn't be necessary anymore. We'll have to followup on the pthread issue next week.

from rules_android_ndk.

Thanks for your work, @ahumesky
Glad to hear you will start the pthread issue.
Thanks again.

from rules_android_ndk.

I see you found a workaround with #5 (comment) glad you are unblocked.

I think unable to find library -lpthread is actually a symptom of this config_setting not working with the starlark version of android_ndk_repository:

https://github.com/tensorflow/tensorflow/blob/93905da81b2995eaba088b715c7d61dcbed51c31/tensorflow/tensorflow.bzl#L449

https://github.com/tensorflow/tensorflow/blob/a801af081952535b541852ad6ad96e0d536f2965/tensorflow/BUILD#L195

Tensorflow would need to use the new value of @androidndk//:toolchain instead of //external:android/crosstool.

Putting a bind in your top-level workspace file may work as a workaround:

bind("android/crosstool", "@androidndk//:toolchain")

If that doesn't work on its own, you might need to set --crosstool_top as well:

--crosstool_top=//external:android/crosstool

(however this might be a catch-22, where other config_settings will expect @androidndk//:toolchain)

from rules_android_ndk.

I hit the pthread issue outside of tensorflow so I imagine it's other places too. Seems like either way we should update that config setting in tensorflow to use the OS from the platforms repo

from rules_android_ndk.

Hi, @ahumesky , Sorry for delay.
I have added the bind(name="//external:android/crosstool", actual="@androidndk//:toolchain") in my top-level WORKSPACE file, but it doesn't work.
I found that tensorflow has many //external:android/crosstool, my grep command outputs are

Should I modify all of these config in tensorflow module? Furthermore, Should I modify all //external:android/crosstool in my external directory ?
By the way, what is the meaning of catch-22 ?
Thanks.

from rules_android_ndk.

You might try

bind(
    name = "android/crosstool",
    actual = "@androidndk//:toolchain",
)

I don't think that the "//external:" is necessary.

By the way, do you have a directory called external at the top-level of your workspace? Bazel treats external differently because of the (unfortunate) binding schemes with bind (we would actually like to get rid of bind one day...). See this issue for more details: bazelbuild/bazel#4508

If the bind above doesn't work, then probably the most expedient solution is to change the config_settings in your local version of tensorflow to use @androidndk//:toolchain instead of //external:android/crosstool until this is sorted out with tensorflow. This is not so great because it makes upgrading tensorflow harder, and requires that you vendor the source code (which you might already be doing), but again it might be the most expedient.

Sorry for "catch-22" -- I should be a little more precise. "Catch-22" is when you have a problem and the solutions for it mutually conflict. So using --crosstool_top=//external:android/crosstool with the bind might fix one set of config_settings, but could cause other config_settings to break, so it's a "catch-22".

from rules_android_ndk.

Hi， @ahumesky
The bind mentioned above doesn't work all the time. So i tried to change the //external:android/crosstool in my local version.
Sorry, The external is not my customized directory but is generated by bazel (a cache directory), which location is ~/.cache/bazel/_bazel_zhu/bf5ae187c183939636c65d4e920e7dc3/external in my machine.

I have moved all //external:android/crosstool to @androidndk//:toolchain located in above external directory manually. Finally, it works well. By the way, is there an update for above change when tensorflow will upgrade in the future?
Because it is not an elegant way.
Thanks for explaining the Catch-22.
Thanks again.

from rules_android_ndk.

Hi, @ahumesky
I have changed api_level value at the top-level of my WORKSPACE.
I found that android_ndk_repository(name = "androidndk", api_level=26) is valid, but android_ndk_repository(name = "androidndk", api_level=25) is error.
Is 26 the smallest number of api level ?
Thanks.

from rules_android_ndk.

Can you share what the error is?

from rules_android_ndk.

Hi, @ahumesky I have changed api_level value at the top-level of my WORKSPACE. I found that android_ndk_repository(name = "androidndk", api_level=26) is valid, but android_ndk_repository(name = "androidndk", api_level=25) is error. Is 26 the smallest number of api level ? Thanks.

Hi, @ahumesky
There is no error but a phenomenon when I set api_level=25.
I have no question about this issue. I close this issue now.
Thanks a lot.
Best wishes.

from rules_android_ndk.