Cross compilation issues about rules_android_ndk HOT 9 CLOSED

The immediate issue here is that --cpu=x86_64 is used with --crosstool_top with its default value (@bazel_tools//tools/cpp:toolchain which is an alias for @local_config_cc//:toolchain), and the default toolchain doesn't have a cpu named x86_64 (the default toolchain uses k8 for x86-64).

The way to address this depends on what you're building:

If you're building an android_binary target with cc_library targets in its dependencies, then just take out --cpu=x86_64. The android_binary target will read --fat_apk_cpu for compiling the cc_library targets in its dependencies. (It's also not necessary to set --host_crosstool_top in this scenario.)

If you're building cc_binary or cc_library targets independently of an android_binary target, then set --crosstool_top=@androidndk//:toolchain, and --cpu to the desired cpu. --android_crosstool_top and --fat_apk_cpu will be ignored.

Note that there are some interactions here with target patterns like //.... If you have an android_binary with cc_library targets in its dependencies, then //... will build the cc_library as both a top-level target, which will use --crosstool_top and --cpu, and as a dependency of an android_binary, which will use --android_crosstool_top and --fat_apk_cpu. We fell for this ourselves here: 2a3c13b

from rules_android_ndk.

A related question: what is the correct approach to select a variant within the select construct?

rules_apple define a whole bunch of "cpu" derived config settings ( https://github.com/bazelbuild/rules_apple/blob/1b42c9f8d2467554eaa49ac80a50cafd2a2507d4/apple/BUILD#L10 ) which then can be handily used to select things:

 src = select({
        ":ios_x86_64": "foo",
        ":ios_armv7": "bar",
})

How shall I achieve the same effect with rules_android_ndk?
(I could not figure a safe way to do this with old NDK rules either and had to come with a bunch of a custom define flags).

from rules_android_ndk.

Ideally the canonical platforms here would work: https://github.com/bazelbuild/platforms
however the android rules haven't been fully migrated to platforms yet, see bazelbuild/bazel#16285
(though it's possible to bridge this with platform mappings: https://bazel.build/concepts/platforms#platform-mappings).

The next best thing is to define config_settings and use those directly:

config_setting(
  name = "x86_64",
  values = {"cpu": "x86_64"},
)

config_setting(
  name = "arm64-v8a",
  values = {"cpu": "arm64-v8a"},
)

cc_library(
    name = "jni",
    srcs = ["jni.cc"],
    deps = select({
      ":x86_64": [":jni_dep_x86_64"],
      ":arm64-v8a": [":jni_dep_arm64"],
    }),
)

cc_library(
    name = "jni_dep_x86_64",
    srcs = ["jni_dep_x86_64.cc"],
    hdrs = ["jni_dep.h"],
)

cc_library(
    name = "jni_dep_arm64",
    srcs = ["jni_dep_arm64.cc"],
    hdrs = ["jni_dep.h"],
)

from rules_android_ndk.

That's what I tried and ended up with the present issue. :-)

In general, I found that trying to double-guess the valid "cpu" values is a process full of misery.

from rules_android_ndk.

Some years ago I was similarly frustrated with "what cpus can I use":
bazelbuild/bazel@6cfa830
however I think that's been refactored out of existence.

What errors are you getting after trying #19 (comment) ?

from rules_android_ndk.

android_binary target with cc_library targets in its dependencies, then just take out --cpu=x86_64

If I take it out, the relevant config_setting is not selected.

from rules_android_ndk.

That suggests that you're building something other than an android_binary target, or something in addition to the android_binary target. Can you share more complete repro steps?

android_binary takes --fat_apk_cpu and --android_crosstool_top and translates them into --cpu and --crosstool_top for each cpu in --fat_apk_cpu for its dependencies (i.e., you get multiple versions of the cc_library targets in its deps). That's why cpu is listed in the config_settings. However, if there are other targets that are getting built as top-level targets (i.e. explicitly listed on the command line, or built through a target pattern like //... or //pkg:all) then they get the "regular" top-level values of --cpu and --crosstool_top. So that suggests that there are other targets that are not in the deps of an android_binary that are getting the "android" value of --cpu, but not the "android" value of --crosstool_top.

from rules_android_ndk.

My project is cross platform - the same project should build for android, apple and linux/windows. There are multiple selectors for things, depending on CPU and OS.
With the old rules, I used the following selector to cover the Android os:

config_setting(
    name = "android_ndk",
    values = {
        "crosstool_top": "@androidndk//:default_crosstool",
    },
)

This, combined with CPU config settings sort of worked for selecting Android on the both CPUs I need.

With the present toolchain, I'm not yet sure how to proceed short of defining a custom, explicit define.

from rules_android_ndk.

I will close this as I think I have figured out a decent enough mix of config_setting and patches to dependencies to work for me.

from rules_android_ndk.