[BUG] tools in genrule can not be built with alternative toolchain / platform

[JanJamaszyk-FlyNow]

Description of the problem / feature request:

In our repository we are maintaining our own toolchain using the platform concept.
However there is no way for us to force a tool specified inside a genrule to be built with our own toolchain, neither to overwrite the default toolchain bazel uses.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

1. Define an alternative toolchain
2. Define a genrule with a target in the "tools" section
3. Build the project with the alternative toolchain using the --platform argument
4. Verify that the alternative toolchain has not been used for the compilation for the targets inside the "tools" section

What operating system are you running Bazel on?

Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal
Kernel: 5.8.0-40-generic

What's the output of bazel info release?

release 4.0.0

Have you found anything relevant by searching the web?

Bazel specifies this behavior as expected:
https://docs.bazel.build/versions/master/be/general.html

[...] they are built using the host configuration, since these tools are executed as part of the build.

However if the default host toolchain is not suitable for compiling the tool there is no way for us to force the usage of an alternative toolchain.

[gregestren]

Hi Jan,

Can you trace out some pseudo-code of what you're expecting? I can't tell from the report if you expect the alternative toolchain to build the target in tools, or to replace that target, or how you expect the --platform change to identify the appropriate toolchain?

Can you also clarify which language's toolchain you mean?

[JanJamaszyk-FlyNow]

Hi Greg,

I am talking about the c++ cc_toolchain.
In our build-file we have:

native.genrule(
    name = name + "_genrule",
    srcs = [src],
    outs = outs,
    tags = genrule_tags,
    tools = ["//tool_to_build"],
    target_compatible_with = ["@//fancy_custom_toolchain"],
)

the build rule of the tool looks like this:

cc_library(
    name = ["tool_to_build"],
    srcs = srcs,
    target_compatible_with = ["@//fancy_custom_toolchain"],
)

as you can see the tool_to_build is not expected to be compatible with the bazel default toolchain, only with the "fancy_custom_toolchain" but as per documentation bazel always uses the default toolchain to build tools and we have not found any means to even redirect the default toolchain to our fancy_custom_toolchain.

Thanks for your help!

[gregestren]

I see.

What about some combination of using exec_tools instead of tools and using --host_platforms?

"target" is the machine the binary you're building will run on. "host" and "exec" are similar concepts that are the machine that actually runs the compilers and linkers. Targets in tools and exec_tools are marked for the latter. --host_platforms specifies the platform for that.

[JanJamaszyk-FlyNow]

Thanks Greg,

that could be a feasible solution for us!
Unfortunately as soon as I specify --host_platform I get:
Configurable attribute "actual" doesn't match this configuration: Could not find a JDK for host execution environment, please explicitly provide one using --host_javabase.
Even though we are not using java anywhere in our build process and do not plan on installing java on all build machines.
Why don't we need java when we use the default toolchain but seem to need it when specifying the host_platform?

[gregestren]

Can you share a simple repro of that error?

[JanJamaszyk-FlyNow]

Interesting, I cannot repro it in a minimal example, looks like one of our dependencies is pulling in the java dependency.
Do you have any idea on how I can debug which package has a java related dependency?
bazel query "deps(//...)" --notool_deps --noimplicit_deps "${args[@]}" --output package
does not give me any JAVA related package.
Could you help me how to find out who is responsible for generating the error:

failed; build aborted: /home/flynow/.cache/bazel/_bazel_flynow/22c102f3a5fb9aa0fbbd6f2c12ffc9f6/external/bazel_tools/tools/jdk/BUILD:490:6: Configurable attribute "actual" doesn't match this configuration: Could not find a JDK for host execution environment, please explicitly provide one using `--host_javabase.`

Thanks a lot for your help!

[JanJamaszyk-FlyNow]

Update, using bazel query "deps(//...)" --output package I found:

Loading: 0 packages loaded
@bazel_tools//tools/jdk
@local_jdk//
@remote_java_tools_darwin//
@remote_java_tools_darwin//java_tools/zlib
@remote_java_tools_linux//
@remote_java_tools_linux//java_tools/zlib
@remote_java_tools_windows//
@remote_java_tools_windows//java_tools/zlib
Loading: 0 packages loaded
Loading: 0 packages loaded

do you have an idea how I can find out who could be pulling in the java dependencies?

[JanJamaszyk-FlyNow]

Okay, I found the issue: cc_test is pulling in the java dependencies.
Please find the repro attached:
bazel_tool_bug.zip
To repro please type:

docker-compose run tool_bug
bazel build //...

[JanJamaszyk-FlyNow]

Hi Greg,
could you repro the issue?
What are the next steps here?
Thanks,
Jan

[gregestren]

Apologies that I slipped on this for a while.

I tried your repro and see the same behavior. Can you show a similar repro that doesn't have the JDK problem (i.e. the original issue you filed, which still had an error, but not that error). Maybe starting from there would make it easier to resolve, especially with a clear repro we can all experimentally adjust.

[JanJamaszyk-FlyNow]

The JDK problem appears as soon as we register a custom c++ toolchain. The only way to get rid of it is to use the standard c++ toolchain. In the meantime we found a workaround by manually specifying host_javabase in bazelrc:
--host_javabase=@remotejdk11_linux//:jdk
But given we are not using java anywhere and this is a bazel internal thing we should not need to do that!

[gregestren]

Some more context:

$ bazel query 'somepath(//:test_that_pulls_java, @local_jdk//:jdk-bin)' --output=label_kind
cc_test rule //:test_that_pulls_java
alias rule @bazel_tools//tools/test:coverage_report_generator
alias rule @remote_coverage_tools//:coverage_report_generator
java_binary rule @remote_coverage_tools//:Main
java_runtime_alias rule @bazel_tools//tools/jdk:current_java_runtime
java_runtime_alias rule @bazel_tools//tools/jdk:legacy_current_java_runtime
alias rule @bazel_tools//tools/jdk:jdk
java_runtime rule @local_jdk//:jdk
filegroup rule @local_jdk//:jdk-bin

That first dep on @bazel_tools//tools/test:coverage_report_generator comes from

bazel/src/main/java/com/google/devtools/build/lib/analysis/BaseRuleClasses.java

Line 238 in 09c621e

attr(":coverage_report_generator", LABEL)

I have no idea why a custom toolchain would trigger that while the default wouldn't. I'll see if I can CC someone familiar with the coverage logic - they'd probably be able to gauge it best.

Aside from that, with the --host_javabase flag, do you get what you want?

[gregestren]

@coeuvre - do you have any insights about the above comment? How --coverage_report_generator ends up producing a Java dependency, but not for the default C++ toolchain?

[coeuvre]

I am not familiar with this part so it could be wrong but it seems that the custom toolchain is using default value of --coverage_report_generator (@bazel_tools//tools/test:coverage_report_generator) which is a java_binary while the default toolchain manages to register gcc/llvm as coverage collector. We might need to do something similar for the custom toolchain.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!