-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Android NDK 16 in Bazel #4068
Comments
I encountered this as well. Didn't initially expect the NDK version to be the cause of those errors, and wasted time trying to hunt down what was wrong with my NDK path. Turns out it was just fine, but I needed to use an older version. |
@dajensen , sorry to hear about your wasted time. Bazel should have emitted a warning that NDK 16 was unsupported. Perhaps we should make that warning an error. |
Any eta on when NDK 16 will be supported @aj-michael? |
@dajensen For what it's worth, the warning isn't very helpful:
The warning text doesn't mean much to me, especially because the exact same message appeared with NDK 15 and the build still worked. "Defaulting to revision 14" actually indicates that Bazel will pretend whatever NDK installed is r14, but it seems like the message says "I'll change your version to rev 14 for you to avoid this problem". I spent ~4 hours trying to understand why the includes weren't compiling, since it looked like Bazel was warning a non-issue. Since Bazel lacks support for the latest NDK in a world where installing old NDKs is not intuitive, and the failures are misleading, I think this has impacted TF quite a bit, as new users haven't been able to follow the demo instructions for the newly released TF Lite for a couple weeks. There's a lot of confusion in the issues referenced above, and many Stack Overflow questions related to this same problem with the NDK (users asking why important headers are missing, etc.) We weren't able to catch the issue sooner because the importance of the NDK version is so low-profile. I think most of this could be alleviated with a much stronger NDK warning -- an Error that explains what's going on would be really helpful, e.g.:
Or if it stays as a warning:
NDK 16 support would be awesome too, but this would alleviate future incompatibilities. I think addressing this somehow should be higher priority than P2. In the meantime, I'm going to update our build instructions to work around the NDK trouble. (May be interesting for @martinwicke @gunan @petewarden) |
We can certainly update the warning text, your 2nd suggestion sounds good. We made this a warning instead of an error on the reasoning that future NDK versions would be backwards compatible with the crosstool, but that hasn't always worked out. We've been focused on getting our android testing support working in bazel (robolectric testing, emulator testing), so we haven't had much time to work on NDK integration. I'll see about getting this higher priority. |
See bazelbuild/bazel#4068 PiperOrigin-RevId: 177264756
See bazelbuild/bazel#4068 PiperOrigin-RevId: 177264756
This change teaches the configure script how to search for Android NDK and SDK installations and create new WORKSPACE rules pointing to them. It also refactors many similar loop-over-user-input functions into using a reusable method (not the more complex ones). Specifying an SDK directory will further query for the available SDK API levels and build tools versions, but it won't perform any compatibility checks. Like other settings, every android-related setting can be set beforehand via an env param. The script will not ask for any Android settings if there are already any android repository rules in the WORKSPACE. The script will emit a warning if using an NDK version newer than 14 due to bazelbuild/bazel#4068. PiperOrigin-RevId: 177989785
Note that support was not that hard when we updated for gomobile: golang/mobile@3ef91fe#diff-bb8d1c5d57784117597766608f27e20c That is, just a matter for properly setting |
Seeing as ndk16 is apparently what you'll be getting with a fresh android sdk install and using the sdkmanager to install |
Suggestion from @angersson on GitHub: #4068 (comment) GITHUB: #4068 RELNOTES: Improved clarity of warning message for unsupported NDK revisions. PiperOrigin-RevId: 184852316
This is being worked on. Please stay tuned here for updates. |
NDK15 changelog: https://android.googlesource.com/platform/ndk/+/ndk-r15-release/CHANGELOG.md Notable changes for this CL: - Clang has been updated to v5.0.300080. - android-9 is not supported anymore. Anything lower than android-14 will default to android-14. - NDK sysroot has been changed to %ndk%/sysroot - Requires additional compilation flags because the headers are now unified in a single location across archs and API levels Also removed NDK 10 checks in integration tests because it is old and we don't test against that anymore. Fixes #3137 Paves the way for r16: #4068 RELNOTES[NEW]: Added Android NDK r15 support, including compatibility with Unified Headers. PiperOrigin-RevId: 187648715
Hi everyone, NDK r16 support has been merged into master. It's not in a release yet, so you will need to build Bazel from master to use it. Please open a new issue if you stumble upon any bugs or have a feature request. Thanks! |
@jin which NDK version does tf.contrib.makefile support now ? |
Now support NDK r16. But I encountered same issue when I tried to execute "compile_android_protobuf.sh" at this page: https://github.com/tensorflow/tensorflow/blob/master/tensorflow/contrib/makefile/README.md Is there any reference or solution about it? |
Changelog: https://android.googlesource.com/platform/ndk/+/ndk-release-r16/CHANGELOG.md > The deprecated headers have been removed. Unified Headers are now simply The Headers. Support for this was added in r15. > libc++ is out of beta and is now the preferred STL in the NDK. Starting in r17, libc++ is the default STL for CMake and standalone toolchains. If you manually selected a different STL, we strongly encourage you to move to libc++. For more details, see this blog post. We bind the default `//external:android/crosstool` in AndroidNdkRepositoryRule before the repository function is evaluated, so changing the default STL will affect the older NDK revisions too. Until we have a new mechanism to specify the default crosstool, users will need to use `--android_crosstool_top=@androidndk//:toolchain-libcpp` to use `libc++`. > GCC, armeabi, mips, mip64 are deprecated but still buildable/useable. We can remove support for these in the r17 configuration. There are no other actionable differences between r15 and r16, so we can reuse the r15 configuration for r16. RELNOTES: Added Android NDK r16 support. Use --cxxopt='-std=c++11` compile with the C++11 standard, and `--android_crosstool_top=@androidndk//:toolchain-libcpp` to use the `libc++` STL. Fixes bazelbuild/bazel#4068 PiperOrigin-RevId: 187664390
Suggestion from @angersson on GitHub: bazelbuild/bazel#4068 (comment) GITHUB: bazelbuild/bazel#4068 RELNOTES: Improved clarity of warning message for unsupported NDK revisions. PiperOrigin-RevId: 184852316
At this moment, build with NDK 16 will cause fatal errors that "stdlib.h" "wchar.h", etc could not found,
The text was updated successfully, but these errors were encountered: