I'm trying to build Tensorflow in ppc64le from source on a fairly recent commit but I'm stumbling on some issues (https://github.com/tensorflow/tensorflow/issues/10306 and https://github.com/bazelbuild/rules_closure/issues/207) that come from bazebuild/rules_closure.
Mostly I need to check whether the target machine is ppc64le (is there any native Bazel way to run something like uname -m?). Then we shouldn't pass '-client' to the JVM calls - unfortunately, as of today there's no support to the C1 (client) compiler in openjdk8 for ppc64le.
Also there are some pre-built x64 binaries (nodejs and protoc) that are downloaded when building rules_closure - which predates portability. I want to know if there's a way to circumvent this issue such as adding links to a repository containing ppcle64 binaries or falling back to the system's binaries.
(I also asked this in the bazel-discuss mailing list)
Why is the -client flag needed at all? Could it be removed for all architectures? Bazel's built-in way to adjust JDK configuration is the java_toolchain() rule (you can see the default java_toolchain Bazel uses in the source repository). If the flag really is needed on some platforms but not others, then a java_toolchain should be added the provides it, and platforms that do not support that flag can use a customized toolchain without the flag.
As far as binaries, the only choice available now to to use the select() rule, checking on the host_cpu setting, to choose a binary that will work on the local platform.
I am actively working on a new feature called Platforms for Bazel (the design doc is publically available). This will allow projects such as TensorFlow or rules_closure to define the platforms they support, and provide different toolchains and configurations, eventually including things like protoc binaries and JDK flags. Unfortunately, while development is going well, updating the native Java rules will take some time. You can track the progress on Github at issue #2219.