Unable to build x86 based unit tests with bazel 6.0.0rc4 because there is no x86 based remote java toolchain #16961
Comments
|
This does not reproduce in bazel 5.3.2, or 5.4.0rc1 This is reproducible in bazel 6.0.0.rc1 |
|
It doesn't seem we ever had support for 32 bit windows: @carpenterjc You should be able to register additional JDKs in your WORKSPACE with |
comius
added
P4
|
The platform is: Toolchain resolution debug: |
|
I have a hunch that somehow there is a dependency introduced which normally supports bazel coverage. However it is picking up the target platform CPU instead of the host platform CPU. |
|
cc_library - no failure |
|
This was most likely introduced by changing exec_constraints to target_constraints in Java tools. I believe behavior of 6.0.0 is more correct. You can resolve the problem by adding default java toolchain for windows x86 to your WORKSPACE. I don't think we should add this by default to Bazel. It's quite possible that the dependecies originate from coverage, if you don't have any other Java deps. |
|
I can confirm we do not use Java, and we never use coverage, as there isn't support form MSVC and windows. I can see this in the dependencies for a cc_test: In this case I think there may be something wrong with the I am reluctant to add a dependencies on |
|
@comius I think I know what's wrong here, will submit a PR soon. Edit: This changed with the |
|
@bazel-io flag |
bazel-io
added
the
potential release blocker
|
I found this issue, which may be adjacent. #15088 |
|
@bazel-io fork 6.0.0 |
bazel-io
removed
the
potential release blocker
comius
added
P2
|
cc @c-mita |
|
If this was introduced by cc_test Starlarkification, this is a regression we should fix. I don't consider it critical for first Bazel LTS release as it's possible to workaround. |
When coverage is disabled, `cc_test` should not depend on the Java LCOV merger tool. This is achieved by using `configuration_field`. Also depend on coverage tools in `exec` rather than `target` configuration, matching Java rules as well as the once-per-build coverage report generator. Fixes bazelbuild#16961 Closes bazelbuild#16994. PiperOrigin-RevId: 494941601 Change-Id: Ie614de713b87bb66d869515676698f1a71cb106e
When coverage is disabled, `cc_test` should not depend on the Java LCOV merger tool. This is achieved by using `configuration_field`. Also depend on coverage tools in `exec` rather than `target` configuration, matching Java rules as well as the once-per-build coverage report generator. Fixes #16961 Closes #16994. PiperOrigin-RevId: 494941601 Change-Id: Ie614de713b87bb66d869515676698f1a71cb106e
Description of the bug:
We have a C++ toolchain with both intel x64 and x86 definitions.
When we build with x64 the tests work fine, when we build with x86 you can see the toolchain resolution doesn't find any remote_jdk_11 with the which matches the CPU.
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Unfortunately: You need a C++ toolchain with x64 and x86 support, we are using platforms.
When but just running bazel build with the x64 platform will work, as soon as we switch the to building with an x86 platform we get the toolchain resolution error.
We had to specify
build --java_runtime_version=remotejdk_11to get the build to work.Which operating system are you running Bazel on?
Windows
What is the output of
bazel info release?release 6.0.0rc4
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD?No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
The text was updated successfully, but these errors were encountered: