Bazel 5.0.0: Local jdk11: no matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type

SimonVleugels commented 2 years ago

Description of the problem / feature request:

When running bazel test in bazel 5.0.0 using a local jdk (11.0.12), we are getting following error:

external/bazel_tools/tools/jdk/BUILD:29:19: While resolving toolchains for target @bazel_tools//tools/jdk:current_java_runtime: no matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type

When not specifying the jdk in the WORKSPACE file and letting bazel fetch the jdk, the tests will run fine. The fetched jdk version is the same as the local one (Fetching https://mirror.bazel.build/openjdk/azul-zulu11.50.19-ca-jdk11.0.12/zulu11.50.19-ca-jdk11.0.12-linux_x64.tar.gz;)

We followed issue-7849 to convert --javabase to --java_runtime_version

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

cppcheck.zip

Go to cppcheck/
Run bazel test --java_runtime_version=remotejdk11_linux cppcheck

What operating system are you running Bazel on?

Docker container based on Ubuntu 20.04

What's the output of `bazel info release`?

release 5.0.0

Have you found anything relevant by searching the web?

Similar issue: Issue-14864 but using remote java repository

Any other information, logs, or outputs that you want to share?

Complete log:

root@077a0680508a:/repo/cppcheck# bazel test --java_runtime_version=remotejdk11_linux cppcheck
ERROR: /root/.cache/bazel/_bazel_root/064c3516a71315be913f5c4fcef123d2/external/bazel_tools/tools/jdk/BUILD:29:19: While resolving toolchains for target @bazel_tools//tools/jdk:current_java_runtime: no matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type
ERROR: Analysis of target '//cppcheck:cppcheck-test-1' failed; build aborted:
INFO: Elapsed time: 0.694s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (22 packages loaded, 83 targets configured)
FAILED: Build did NOT complete successfully (22 packages loaded, 83 targets configured)

SimonVleugels commented 2 years ago

We made progress and got our cppcheck running.

The flag --tool_java_runtime_version=remote_jdk11 was missing and the definition of the repository in the WORKSPACE needed to be converted from local_repository to local_java_repository:

load("@bazel_tools//tools/jdk:local_java_repository.bzl", "local_java_repository")
local_java_repository(
    name = "remotejdk11_linux",
    version = "11",
    java_home  = "/build/remotejdk11_linux/",
)

Our unittests are still facing the following error:

ERROR: /repo/vleugels/sw3/bazel-cache/base/external/bazel_tools/tools/jdk/BUILD:474:27: While resolving toolchains for target @bazel_tools//tools/jdk:remote_jdk11: no matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type

It seems that it's not taking the correct jdk. @lberki You made the changes in Issue-7849, are we still missing a bazel flag?

The bazel flags we are using regarding java are: --java_runtime_version=remotejdk11_linux --tool_java_runtime_version=remotejdk11_linux

When running the unittests in bazel with --toolchain_resolution_debug, I get following output:

INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/jdk:runtime_toolchain_type -> toolchain @remotejdk11_linux//:remotejdk11_linux
INFO: ToolchainResolution: Type @bazel_tools//tools/jdk:runtime_toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @remotejdk11_linux//:remotejdk11_linux; mismatching config settings: remotejdk11_linux_name_version_setting

The mismatching config settings error is not occurring when running cppcheck

comius commented 2 years ago

Our unittests are still facing the following error

I couldn't reproduce this. With the WORKSPACE and the flags from previous comment cppcheck.zip works; like you're saying.

For unittests I'd need additional reproducer.

Some additional info for debugging: remotejdk11_linux_name_version_setting matches "remotejdk11_linux_11" (name + version) remotejdk11_linux_name_setting matches "remotejdk11_linux" remotejdk11_linux_version_setting matches "11" in your configuration.

See https://cs.opensource.google/bazel/bazel/+/master:tools/jdk/local_java_repository.bzl;l=67-80;drc=32d1606dac2fea730abe174c41870b7ee70ae041

SimonVleugels commented 2 years ago

After some further investigating, we figured out it's caused by using bazel coverage for our unittests. Running cc_test with a local jdk is successful when using bazel test but isn't with bazel coverage.

Reproducible example:

Download: example.zip
Unzip in /tmp/example
In /tmp/example run bazel coverage --java_language_version=11 --java_runtime_version=remotejdk11_linux --tool_java_language_version=11 --tool_java_runtime_version=remotejdk11_linux tests:unittests

Logs: Successful (using bazel test):

/tmp/example# bazel test --java_language_version=11 --java_runtime_version=remotejdk11_linux --tool_java_language_version=11 --tool_java_runtime_version=remotejdk11_linux tests:unittests
DEBUG: Rule 'com_google_googletest' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "5cf189eb6847b4f8fc603a3ffff3b0771c08eec7dd4bd961bfd45477dd13eb73"
DEBUG: Repository com_google_googletest instantiated at:
  /tmp/example/WORKSPACE:9:13: in <toplevel>
Repository rule http_archive defined at:
  /root/.cache/bazel/_bazel_root/89a35363ec8de7131a16c2ed7419999a/external/bazel_tools/tools/build_defs/repo/http.bzl:364:31: in <toplevel>
INFO: Analyzed target //tests:unittests (0 packages loaded, 0 targets configured).
INFO: Found 1 test target...
Target //tests:unittests up-to-date:
  bazel-bin/tests/unittests
INFO: Elapsed time: 0.303s, Critical Path: 0.01s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
//tests:unittests                                               (cached) PASSED in 0.0s

Executed 0 out of 1 test: 1 test passes.
INFO: Build completed successfully, 1 total action

Failing (using bazel coverage):

/tmp/example# bazel coverage --java_language_version=11 --java_runtime_version=remotejdk11_linux --tool_java_language_version=11 --tool_java_runtime_version=remotejdk11_linux tests:unittests
INFO: Using default value for --instrumentation_filter: "^//tests[/:]".
INFO: Override the above default with --instrumentation_filter
INFO: Build options --collect_code_coverage and --instrumentation_filter have changed, discarding analysis cache.
DEBUG: Rule 'com_google_googletest' indicated that a canonical reproducible form can be obtained by modifying arguments sha256 = "5cf189eb6847b4f8fc603a3ffff3b0771c08eec7dd4bd961bfd45477dd13eb73"
DEBUG: Repository com_google_googletest instantiated at:
  /tmp/example/WORKSPACE:9:13: in <toplevel>
Repository rule http_archive defined at:
  /root/.cache/bazel/_bazel_root/89a35363ec8de7131a16c2ed7419999a/external/bazel_tools/tools/build_defs/repo/http.bzl:364:31: in <toplevel>
ERROR: /root/.cache/bazel/_bazel_root/89a35363ec8de7131a16c2ed7419999a/external/bazel_tools/tools/jdk/BUILD:474:27: While resolving toolchains for target @bazel_tools//tools/jdk:remote_jdk11: no matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type
ERROR: Analysis of target '//tests:unittests' failed; build aborted:
INFO: Elapsed time: 0.595s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 754 targets configured)
FAILED: Build did NOT complete successfully (0 packages loaded, 754 targets configured)

Our temporary workaround is to install jdk in our build environment and set JAVA_HOME to /usr/lib/jvm/java-11-openjdk.

UlasSAYGINIM commented 2 years ago

can we have installed for all needed dependencies or tools or toolchains in our build environment and tell the bazel, you can use local ones , no need to download anything? how can we replace build configs of project to look all tools and chains in local environment?

UlasSAYGINIM commented 2 years ago

like use google v8 javascript engine in local environment? and all of the others.

finn-ball commented 2 years ago

@comius - I also came across this problem with my own projects and have also managed to reproduce with the examples given in the zip file.

Enoch9091 commented 1 year ago

I also met the same problem. since Im behind a proxy, the default jdk is unavailable. any other solutions now?

fmeum commented 1 year ago

The problem in https://github.com/bazelbuild/bazel/issues/15035#issuecomment-1077457921 goes away if you rename the JDK repository to something other than remotejdk11_linux such as my_remotejdk11_linux. The auto-configured JDKs in @bazel_tools//tool/jdk seem to reference these external repositories with special names in ways that essentially cause a cycle in toolchain resolution.

bazelbuild / bazel