--incompatible_remove_legacy_whole_archive produces empty .so binary

[korDen]

Noticed this issue while migrating from bazel 0.29.1 to 1.0.0

I have an Android app that has NO java code (AndroidManifest defines android:hasCode="false"), and all the implementation is in JNI (lots of code).

bazel 0.29.1 produces a 290kb libjni.so binary
bazel 1.0.0 produces 6444 libjni.so binary. All the code is essentially stripped (ANactiveActivity_onCreate is missing, along with everything it calls).

I tracked it down to --incompatible_remove_legacy_whole_archive flag. Once enabled on 0.29.1, it produces the same broken .so file.

Not sure if it's related, but it could have something to do with my app not having any Java code:

<activity android:name="android.app.NativeActivity">
  <meta-data android:name="android.app.lib_name" android:value="jni" />
  <!-- skipped -->
</activity>

This creates NativeActivity which loads libjni.so. With 1.0.0 (or with --incompatible_remove_legacy_whole_archive) produced binary is a toast.

[korDen]

I guess it can be solved by including alwayslink = True in cc_library but that feels wrong.

[hlopko]

I presume you're creating the final shared library using cc_binary(linkshared =1,...) way right? Does this cc_binary have sources? Which android ndk are you using?

[hlopko]

Closing for inactivity, please complain to reopen :)

[arturdryomov]

@hlopko, hey, I think it relates to #10323 which essentially breaks the official NDK example (see bazelbuild/examples#125 as well). Setting alwayslink indeed helps. Feels like since 1.0.0 rules_android started to strip everything from native binaries for some reason. Also seems like this happens after the native library is built since both commands below produce the same libjni_lib.so.

USE_BAZEL_VERSION="0.29.1" bazelisk build //app/src/main:jni_lib --crosstool_top=@androidndk//:default_crosstool --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --cpu=x86
USE_BAZEL_VERSION="1.0.0" bazelisk build //app/src/main:jni_lib --crosstool_top=@androidndk//:default_crosstool --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --cpu=x86

[arturdryomov]

Seems to be related to #7362 as well. Actually, it was explicitly mentioned but didn’t get into the documentation and samples.

@hlopko, can you please explain for dummies like me what’s happening? Feels like alwayslink should be set to True for all Android native libraries — but I still don’t get what should be done: applications should do the switch themselves (the Android documentation should be adjusted then) or it can be applied for all Android targets on the rule level.