no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type

[Gunnar Wagenknecht]

Hi,

bazel coverage //foo:test  gives me the following error:

ERROR: While resolving toolchains for target //foo:test: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type
ERROR: Analysis of target '//foo:test' failed; build aborted: no matching toolchains found for types @bazel_tools//tools/cpp:toolchain_type

I'm trying to understand why. 

//foo:test is a java junit5 test target.
gcc is installed on the machine.

The environment is a CentOS 7 container. A simple cc_library works fine. Thus, it must be something else that Bazel expects but isn't there. 

Any ideas how I can debug which tool is missing?

-Gunnar

-- 
Gunnar Wagenknecht
gun...@wagenknecht.org, http://guw.io/

[John Cater]

This is pretty surprising if cc_library works. Are you setting the "-incompatible_enable_cc_toolchain_resolution" flag that would turn on the use of cc toolchain type in the first place?

I don't know much about the coverage system: my guess is that it's trying to build a tool for the host configuration, and for some reason the host configuration can't find a valid cc toolchain.

A quick test to validate this would be to try the following:

```

touch WORKSPACE

cat >>hello.cc <<EOF

#include <iostream>

int main(int argc, char* argv[]) {

  std::cout << "Hello!" << std::endl;

  return 0;

}

EOF

cat >>BUILD.bazel <<EOF

cc_binary(

    name = "tool",

    srcs = ["hello.cc"],

)

genrule(

    name = "demo",

    outs = ["demo.out"],

    cmd = "\$(location :tool) > \$@",

    tools = [":tool"],

)

EOF

bazel build //:demo

```

This creates a simple cc binary, then uses it as the tool in a genrule, so it will be built in the host configuration. If this builds properly, then that isn't your problem, and if it gives a similar error to the coverage problem, it helps to pinpoint your cc toolchain configuration as the problem.

John C

[Gunnar Wagenknecht]

On Dec 18, 2019, at 07:22, 'John Cater' via bazel-discuss <bazel-...@googlegroups.com> wrote:

This is pretty surprising if cc_library works. Are you setting the "-incompatible_enable_cc_toolchain_resolution" flag that would turn on the use of cc toolchain type in the first place?

I don't know much about the coverage system: my guess is that it's trying to build a tool for the host configuration, and for some reason the host configuration can't find a valid cc toolchain.

So, I was able to figure it out yesterday. It was specific to coverage. Build as well as Test did also fail. 

It seems to be related to the remote JDK, which I had put in to force it to JDK 11.

That's a .bazelrc file in version control of the project:

build --javabase=@bazel_tools//tools/jdk:remote_jdk11

Once I introduced a specific one for the CentOS CI servers, which replaces the remote JDK with a local one, everything started working fine.

# use the local JDK for everything

build --define=ABSOLUTE_JAVABASE=/opt/tools/Linux/jdk/...

build --host_javabase=@bazel_tools//tools/jdk:absolute_javabase

build --host_java_toolchain=@bazel_tools//tools/jdk:toolchain_java11

build --java_toolchain=@bazel_tools//tools/jdk:toolchain_java11

HTH,

[John Cater]

That's still a bit surprising. If you manage to get a consistent reproduction, please do consider filing a bug on Github, so we can track this. Unfortunately, lots of things do have a dependency on C++ at this time, so it's fairly hard to use Bazel without a C++ compiler installed, but we should at least be explicit about why.

[Gunnar Wagenknecht]

> On Dec 18, 2019, at 10:44, John Cater <jca...@google.com> wrote:
>
> That's still a bit surprising. If you manage to get a consistent reproduction, please do consider filing a bug on Github, so we can track this. Unfortunately, lots of things do have a dependency on C++ at this time, so it's fairly hard to use Bazel without a C++ compiler installed, but we should at least be explicit about why.

I would love to file a bug but it's hard to know if you can really reproduce it. I'll try with an OSS available Docker image.

The thing is: gcc and gcc-c++ was installed in the CentOS image all the time. Thus, it seemed to be either an issue with finding this *or* something is bogus when the remote_jdk role comes into play.

-Gunnar