Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bazel 4.0.0 - "ERROR: cc_toolchain does not have mandatory provider 'ProtoInfo'. " when building project with protobuf #12887

Open
michael-isaev opened this issue Jan 22, 2021 · 17 comments
Labels
P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Rules-CPP Issues for C++ rules type: support / not a bug (process)

Comments

@michael-isaev
Copy link

Description of the problem / feature request:

I am developing a Paragraph framework that builds with bazel and depends on protobuf. After updating bazel to version 4.0.0 I got an error:

ERROR: /usr/local/google/home/misaev/.cache/bazel/_bazel_misaev/c13aabee7e17f0c08e7db24fb9d21398/external/com_google_protobuf/BUILD:975:21: in proto_lang_toolchain rule @com_google_protobuf//:cc_toolchain: '@com_google_protobuf//:cc_toolchain' does not have mandatory provider 'ProtoInfo'.

The issue appeared only after bazel was updated, the issue disappears if bazel is downgraded to the version 3.7.2. It's possible the issue is with protobuf itself and/or rules_proto, but since the error is fixed with downgrading, I assume this is a reasonable place for a bug description.

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

The simplest way is

  1. clone paragraph
git clone git@github.com:google/paragraph.git
cd paragraph/
  1. checkout initial commit that does not have dependency on Tensorflow (hence it's apparent the issue is with combination of bazel and rules_proto/protobuf)
git checkout db503f48fabbac47fe9a597feacb7be2226b6832
  1. build it and it fails
bazel test ...

What operating system are you running Bazel on?

Linux 5.7.17-1rodete4-amd64 #1 SMP Debian 5.7.17-1rodete4 (2020-10-01) x86_64 GNU/Linux

What's the output of bazel info release?

misaev@misaev2:~/dev/paragraph$ bazel info release
release 4.0.0

Have you found anything relevant by searching the web?

Yes, it looks like Tensorflow had similar issues yesterday updating to bazel 4.0.0 and shortly after that performing a rollback. Paragraph pretty much only depends on protobuf (through rules_proto) and abseil, so it should be more convenient to use it as a minimally failing example.

@Yannic
Copy link
Contributor

Yannic commented Jan 23, 2021

This is caused by an incompatible change that was flipped in Bazel 4.0.0: #11694

All you need to do to fix that issue is to upgrade either rules_proto to at least cfdc2fa31879c0aebe31ce7702b1a9c8a4be02d2 or make sure you use at least Protobuf 3.13 in you build.

See also https://groups.google.com/g/bazel-discuss/c/gRGUbnpxkUU/m/JV4wZnm6AQAJ

@bjacklyn
Copy link

@Yannic upgrading rules_proto to cfdc2fa31879c0aebe31ce7702b1a9c8a4be02d2 and using protobuf-3.11.3 does not appear to work (same error). Are you suggesting the rules_proto upgrade will fix this only because rules_proto itself depends on protobuf-3.13.0 and thus protobuf-3.13.0 is mandatory to use bazel 4, or is it in fact possible to use the newer rules_proto with an older protobuf to resolve this error?

@bjacklyn
Copy link

Actually it looks like if both of these commits are applied (i.e. patches = [...] on the http_archive) to the older protobufs version it works for me (it builds at least):

@limdor
Copy link
Contributor

limdor commented Jan 28, 2021

@bjacklyn out of curiosity, are you using prot_library native in your code or the one from rules_proto? Maybe that is the difference?

@bjacklyn
Copy link

@limdor -- I'm using rules_proto, for example:

# cat BUILD 
load("@rules_cc//cc:defs.bzl", "cc_proto_library")
load("@rules_proto//proto:defs.bzl", "proto_library")

proto_library(
    name = "api_proto",
    srcs = ["api.proto"],
)

cc_proto_library(
    name = "api_proto_library",
    deps = [":api_proto"],
)

# cat WORKSPACE 
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "com_google_protobuf",
    strip_prefix = "protobuf-3.11.3",
    urls = ["https://github.com/protocolbuffers/protobuf/archive/v3.11.3.tar.gz"],
)

load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
protobuf_deps()

Which results in this error:

# /usr/bin/bazel build //...
ERROR: /root/.cache/bazel/_bazel_root/f2c2c027f0248b549cd3c5db744b5c20/external/com_google_protobuf/BUILD:1006:21: in proto_lang_toolchain rule @com_google_protobuf//:cc_toolchain: '@com_google_protobuf//:cc_toolchain' does not have mandatory provider 'ProtoInfo'.
ERROR: Analysis of target '//:api_proto_library' failed; build aborted: Analysis of target '@com_google_protobuf//:cc_toolchain' failed
INFO: Elapsed time: 0.321s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1 packages loaded, 66 targets configured)

Updating to 3.13.0 works as mentioned by yannic:

# cat WORKSPACE 
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "com_google_protobuf",
    strip_prefix = "protobuf-3.13.0",
    urls = ["https://github.com/protocolbuffers/protobuf/archive/v3.13.0.tar.gz"],
)

load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
protobuf_deps()

But I'm trying to only upgrade bazel at the moment -- upgrading protobufs probably means upgrading a ton of other rules_*, grpc, abseil, etc (and all the validation that goes along with doing that) -- which I'd rather not have to do in order to upgrade bazel if I can avoid it :)

Which is why I'm using the workaround I found of applying those 2 commits mentioned above as patches:

# cat WORKSPACE 
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "com_google_protobuf",
    strip_prefix = "protobuf-3.11.3",
    urls = ["https://github.com/protocolbuffers/protobuf/archive/v3.11.3.tar.gz"],
    patches = ["//:protobuf_protoinfo_prepare.patch", "//:protobuf_protoinfo_apply.patch"],
)

load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
protobuf_deps()

@limdor
Copy link
Contributor

limdor commented Jan 28, 2021

Thanks @bjacklyn I'm on the same process like you. I updated rules_proto to the latest available in bazel mirror but unfortunately was not having commit cfdc2fa31879c0aebe31ce7702b1a9c8a4be02d2.
Now I tried to update protobuf but it is not so straightforward. I will try first updating rules_proto to the latest that includes cfdc2fa31879c0aebe31ce7702b1a9c8a4be02d2 and then if not I will also try with the patches.
Unfortunately I am using a much older protobuf version, let's see if the patches will work.

@limdor
Copy link
Contributor

limdor commented Feb 4, 2021

I can confirm the same what @bjacklyn was saying, updating rules_proto only is not enough. I still do not have the information of which is the minimum version of com_google_protobuf that can be used applying cleanly the patches mentioned. If someone has this information would be very great to add it to this ticket.

@gonzojive
Copy link
Contributor

My guess is that an earlier version of com_google_protobuf is getting loaded implicitly by some code in your WORKSPACE file.

For me, moving the rules_proto section high up in the WORKPACE file fixed the problem:

git_repository(
    name = "rules_proto",
    commit = "cfdc2fa31879c0aebe31ce7702b1a9c8a4be02d2",
    remote = "https://github.com/bazelbuild/rules_proto.git",
)

@gonzojive
Copy link
Contributor

gonzojive commented Feb 21, 2021

It also looks like your WORKSPACE is missing the recommended

load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")

protobuf_deps()

patch to fix:

diff --git a/WORKSPACE b/WORKSPACE
index 7a13760..f399e51 100644
--- a/WORKSPACE
+++ b/WORKSPACE
@@ -1,21 +1,24 @@
 load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive", "http_file")
+load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
 
 # rules_cc defines rules for generating C++ code from Protocol Buffers.
 
 # rules_proto defines abstract rules for building Protocol Buffers.
 hash = "97d8af4"
-http_archive(
+git_repository(
     name = "rules_proto",
-    urls = [
-        "https://github.com/bazelbuild/rules_proto/tarball/" + hash,
-    ],
-    type = "tar.gz",
-    strip_prefix = "bazelbuild-rules_proto-" + hash,
+    commit = "cfdc2fa31879c0aebe31ce7702b1a9c8a4be02d2",
+    remote = "https://github.com/bazelbuild/rules_proto.git",
 )
+
 load("@rules_proto//proto:repositories.bzl", "rules_proto_dependencies", "rules_proto_toolchains")
 rules_proto_dependencies()
 rules_proto_toolchains()
 
+load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
+
+protobuf_deps()
+
 release = "1.10.0"
 http_archive(
   name = "googletest",

@limdor
Copy link
Contributor

limdor commented Apr 23, 2021

It also looks like your WORKSPACE is missing the recommended

load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")

protobuf_deps()

patch to fix:

diff --git a/WORKSPACE b/WORKSPACE
index 7a13760..f399e51 100644
--- a/WORKSPACE
+++ b/WORKSPACE
@@ -1,21 +1,24 @@
 load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive", "http_file")
+load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")
 
 # rules_cc defines rules for generating C++ code from Protocol Buffers.
 
 # rules_proto defines abstract rules for building Protocol Buffers.
 hash = "97d8af4"
-http_archive(
+git_repository(
     name = "rules_proto",
-    urls = [
-        "https://github.com/bazelbuild/rules_proto/tarball/" + hash,
-    ],
-    type = "tar.gz",
-    strip_prefix = "bazelbuild-rules_proto-" + hash,
+    commit = "cfdc2fa31879c0aebe31ce7702b1a9c8a4be02d2",
+    remote = "https://github.com/bazelbuild/rules_proto.git",
 )
+
 load("@rules_proto//proto:repositories.bzl", "rules_proto_dependencies", "rules_proto_toolchains")
 rules_proto_dependencies()
 rules_proto_toolchains()
 
+load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
+
+protobuf_deps()
+
 release = "1.10.0"
 http_archive(
   name = "googletest",

protobuf_deps() is only available from protobuf 3.8.0. The question here is what is the minimum version of protobuf supported with Bazel 4

@mlekena
Copy link

mlekena commented Jun 12, 2021

Just want to echo that the code snippet above does work... Just pulled this code down recently and the issue still exists in the code base so the above is needed to get that working.

copybara-service bot pushed a commit to tensorflow/tensorflow that referenced this issue Nov 29, 2021
Upgrading protobuf has failed in #52853, this change is to work around issues in older protobuf versions for upgrading Bazel by cherry-picking two protobuf commits.

See bazelbuild/bazel#12887 (comment)

	Commit 1:

	[bazel] Use proto_library targets to exclude WKPs from code-gen

	This prepares protobuf for a future release of Bazel which will make
	`ProtoInfo` mandatory for `proto_lang_toolchain.blacklisted_protos`.

	Commit 2:

	[bazel] Remove bootstrap hack from cc_proto_library and add interop with proto_library

	Bazel had a native `cc_proto_library` for more than 2 years now.
	This is the first step towards removing that rule from the Protobuf
	repo.

PiperOrigin-RevId: 412892006
Change-Id: I424974d3f5be371d6b83d62fc24683cd84ff2585
tomtseng added a commit to ParAlg/ParClusterers that referenced this issue Dec 14, 2021
On my macOS machine with Bazel 4.2.1, when I try to build, I get an immediate build error:
```
ERROR: /private/var/tmp/_bazel_t/12fcc22211704038f32f3c5236102e5e/external/com_google_protobuf/BUILD:979:21: in proto_lang_toolchain rule @com_google_protobuf//:cc_toolchain: '@com_google_protobuf//:cc_toolchain' does not have mandatory provider 'ProtoInfo'.
ERROR: Analysis of target '//clusterers/ldd_clusterer:ldd-clusterer' failed; build aborted: Analysis of target '@com_google_protobuf//:cc_toolchain' failed
```
[Moving the `rules_proto` section higher in `WORKSPACE`](bazelbuild/bazel#12887 (comment)) fixes this issue on my machine.

Building with this change on an Ubuntu 18.04 machine with Bazel 3 still works.

(I still can't build on macOS because of `external/gbbs/gbbs/io.cc:20:11: error: use of undeclared identifier ‘M_MMAP_MAX’` but that's a separate issue.)
@weimch
Copy link

weimch commented Dec 20, 2021

Hi, I found that just add below flags when you build with bazel-4.0 or above, everything will be fine.

build --incompatible_blacklisted_protos_requires_proto_info=false

@desh-woes
Copy link

Is there an update on this issue? I am also encountering the same error.

@pksinghus
Copy link

Hi, I found that just add below flags when you build with bazel-4.0 or above, everything will be fine.

build --incompatible_blacklisted_protos_requires_proto_info=false

Fantastic. I was trying to build scann. Wouldn't build with bazel 6, wouldn't build with bazel 5. Then I moved down to bazel 4, added this property and now it is building. This property was not recognized by bazel 5 and 6.

@ermeiyao
Copy link

so we can't upgrade to bazel 5 or 6 ?

@weimch
Copy link

weimch commented Aug 11, 2023

so we can't upgrade to bazel 5 or 6 ?

It does not work beyond bazel 5 because bazel does not support incompatible_blacklisted_protos_requires_proto_info since bazel5. See this issue for details.

You should upgrade protobuf to higher version(maybe higher than 3.14.0, sorry I don't remeber the protobuf specified version), and remove the bazel compile flag incompatible_blacklisted_protos_requires_proto_info to resolve this problem when you use bazel-5 or beyond.

Copy link

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 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Rules-CPP Issues for C++ rules type: support / not a bug (process)
Projects
None yet
Development

No branches or pull requests