Added grpc@1.70.1

[veblush]

Based on 1.69.0, some changes are

• Used the commit instead of tag as the necessary commits were made on https://github.com/grpc/grpc/commits/v1.70.x after 1.70.0 tag was created.
• Removed grpc-java from its dependency.
  • Removed more unnecessary dependencies that are not required just to consume public targets ([CI] Clean-up bzlmod deps grpc/grpc#38626)
• Removed add_module_bazel.patch as the repo has MODULE.bazel.
• Removed disable-layering-check.patch since mac fixed this layering issue by [Backport-v1.70.x] Added missing absl/status to BUILD grpc/grpc#38585.
• Removed patches for grpc_deps.bzl and bazel/cc_grpc_library.bzl as the repo already got those changes.

[veblush]

@bazel-io skip_check unstable_url

[bazel-io]

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (grpc) have been updated in this PR.
Please review the changes. You can view a diff against the previous version in the "Generate module diff" check.

[veblush]

@mering and @meteorcloudy Would you take a look at this? Thanks!

[Wyverald]

very nice! I'd still like @mering at least to take a look, though.

Require module maintainers' approval for newly pushed changes.

[meteorcloudy]

@veblush Please take a look at the failures on windows, you should be able to reproduce on a windows machine with

git clone https://github.com/bazelbuild/bazel-central-registry.git
cd bazel-central-registry && git fetch origin pull/3671/head && git checkout FETCH_HEAD
bazel run //tools:setup_presubmit_repos -- --module grpc@1.70.0

then follow the instruction.

See https://github.com/bazelbuild/bazel-central-registry/tree/main/docs#reproduce-presubmit-builds-locally

(Well, there is a small bug to fix #3694)

[veblush]

bazel run //tools:setup_presubmit_repos -- --module grpc@1.70.0

I've got this error when running the command you mentioned above on Cloudtop.

$ bazel run //tools:setup_presubmit_repos -- --module grpc@1.70.0
Starting local Bazel server (8.0.1) and connecting to it...
INFO: Running command line: bazel-bin/tools/setup_presubmit_repos <args omitted>
2025-01-30 10:52:33,050 - INFO: Testing using registry at: /usr/local/google/home/veblush/git/a/bazel-central-registry
2025-01-30 10:52:33,053 - INFO: Creating anonymous module repo at: /usr/local/google/home/veblush/git/a/bazel-central-registry/temp_test_repos/grpc/1.70.0/anonymous_module
2025-01-30 10:52:33,054 - INFO: Anonymous module repo ready at: /usr/local/google/home/veblush/git/a/bazel-central-registry/temp_test_repos/grpc/1.70.0/anonymous_module

No task found for the host platform: linux
Please check /usr/local/google/home/veblush/git/a/bazel-central-registry/modules/grpc/1.70.0/presubmit.yml on which targets to build.

2025-01-30 10:52:33,054 - INFO: No test module task config found for grpc@1.70.0

[meteorcloudy]

@veblush Please rebase your branch to HEAD to get #3694

Also, the failure is Windows only, so it probably couldn't be reproduced on a cloudtop Linux VM

[veblush]

Please rebase your branch to HEAD to get #3694

Yep, it solved this problem and I'm now able to run the test on both Cloudtop and Windows VM.

[veblush]

@meteorcloudy I've resolved the initial Windows presubmit linking error (see grpc/grpc#38648), but came across a new one which is quite similar to the initial one.

   Creating library bazel-out/x64_windows-fastbuild/bin/external/abseil-cpp~/absl/base/base.if.lib and object bazel-out/x64_windows-fastbuild/bin/external/abseil-cpp~/absl/base/base.if.exp
spinlock.obj : error LNK2019: unresolved external symbol "void __cdecl absl::lts_20240722::raw_log_internal::RawLog(enum absl::lts_20240722::LogSeverity,char const *,int,char const *,...)" (?RawLog@raw_log_internal@lts_20240722@absl@@YAXW4LogSeverity@23@PEBDH1ZZ) referenced in function "void __cdecl absl::lts_20240722::base_internal::CallOnceImpl<class <lambda_78cd9549fdc6064a2f0cb01c847c3268> >(struct std::atomic<unsigned int> *,enum absl::lts_20240722::base_internal::SchedulingMode,class <lambda_78cd9549fdc6064a2f0cb01c847c3268> &&)" (??$CallOnceImpl@V<lambda_78cd9549fdc6064a2f0cb01c847c3268>@@$$V@base_internal@lts_20240722@absl@@YAXPEAU?$atomic@I@std@@W4SchedulingMode@012@$$QEAV<lambda_78cd9549fdc6064a2f0cb01c847c3268>@@@Z)
sysinfo.obj : error LNK2001: unresolved external symbol "void __cdecl absl::lts_20240722::raw_log_internal::RawLog(enum absl::lts_20240722::LogSeverity,char const *,int,char const *,...)" (?RawLog@raw_log_internal@lts_20240722@absl@@YAXW4LogSeverity@23@PEBDH1ZZ)
spinlock.obj : error LNK2019: unresolved external symbol "unsigned int __cdecl absl::lts_20240722::base_internal::SpinLockWait(struct std::atomic<unsigned int> *,int,struct absl::lts_20240722::base_internal::SpinLockWaitTransition const * const,enum absl::lts_20240722::base_internal::SchedulingMode)" (?SpinLockWait@base_internal@lts_20240722@absl@@YAIPEAU?$atomic@I@std@@HQEBUSpinLockWaitTransition@123@W4SchedulingMode@123@@Z) referenced in function "void __cdecl absl::lts_20240722::base_internal::CallOnceImpl<class <lambda_78cd9549fdc6064a2f0cb01c847c3268> >(struct std::atomic<unsigned int> *,enum absl::lts_20240722::base_internal::SchedulingMode,class <lambda_78cd9549fdc6064a2f0cb01c847c3268> &&)" (??$CallOnceImpl@V<lambda_78cd9549fdc6064a2f0cb01c847c3268>@@$$V@base_internal@lts_20240722@absl@@YAXPEAU?$atomic@I@std@@W4SchedulingMode@012@$$QEAV<lambda_78cd9549fdc6064a2f0cb01c847c3268>@@@Z)
sysinfo.obj : error LNK2001: unresolved external symbol "unsigned int __cdecl absl::lts_20240722::base_internal::SpinLockWait(struct std::atomic<unsigned int> *,int,struct absl::lts_20240722::base_internal::SpinLockWaitTransition const * const,enum absl::lts_20240722::base_internal::SchedulingMode)" (?SpinLockWait@base_internal@lts_20240722@absl@@YAIPEAU?$atomic@I@std@@HQEBUSpinLockWaitTransition@123@W4SchedulingMode@123@@Z)
spinlock.obj : error LNK2019: unresolved external symbol AbslInternalSpinLockWake_lts_20240722 referenced in function "void __cdecl absl::lts_20240722::base_internal::SpinLockWake(struct std::atomic<unsigned int> *,bool)" (?SpinLockWake@base_internal@lts_20240722@absl@@YAXPEAU?$atomic@I@std@@_N@Z)
sysinfo.obj : error LNK2001: unresolved external symbol AbslInternalSpinLockWake_lts_20240722
spinlock.obj : error LNK2019: unresolved external symbol AbslInternalSpinLockDelay_lts_20240722 referenced in function "void __cdecl absl::lts_20240722::base_internal::SpinLockDelay(struct std::atomic<unsigned int> *,unsigned int,int,enum absl::lts_20240722::base_internal::SchedulingMode)" (?SpinLockDelay@base_internal@lts_20240722@absl@@YAXPEAU?$atomic@I@std@@IHW4SchedulingMode@123@@Z)
bazel-out\x64_windows-fastbuild\bin\external\abseil-cpp~\absl\base\base_2caf69b4.dll : fatal error LNK1120: 4 unresolved externals

Because this error came from Abseil, I'm unsure whether a code fix is required, or if I can resolve it by adjusting the Bazel build or test configuration.

Note that this error occured when building this absl/base and it has a proper raw_logging_internal dependency that defines RawLog function.

[meteorcloudy]

Linking external/abseil-cpp~/absl/base/base_2caf69b4.dll failed: (Exit 1120): link.exe failed: error executing CppLink command (from target @@abseil-cpp~//absl/base:base)

So, looks like this is dynamic linking error caused by @grpc//examples/protos:helloworld_py_pb2_grpc, which transitively depends on @grpc//src/python/grpcio/grpc/_cython:cygrpc which is a pyx_library that requires all deps to be built as a dynamic library.

Dynamic linking works very differently on Windows, basically all symbols are by default invisible and requires some operations to export them manually. You can check this doc for more details.

Note that this error occured when building this absl/base and it has a proper raw_logging_internal dependency that defines RawLog function.

RawLog isn't decorated with __declspec(dllexport), therefore it is not visible.

Bazel does offer a windows_export_all_symbols feature (similar to the CMake one) to automatically export all symbols from a cc_library.

You can add this features to all corresponding cc_library, but I tried that and it feels a bit like a rabbit hole and you'll need to do that in BUILD files of abseil, boringssl, etc.

Or you can add --features=windows_export_all_symbols in the command line which export all symbols, but that unfortunately will easily hit the limitation of symbol numbers to be exported.

LINK : fatal error LNK1189: library limit of 65535 objects exceeded

TensorFlow implemented a custom solution to filter out unnecessary symbols. But that requires quite a bit of effort.

I think for now, we could probably exclude @grpc//examples/protos:helloworld_py_pb2_grpc on windows and figure out a solution to export symbols on windows properly later. Maybe cc_shared_library could help, but I haven't looked into it.

/cc @pzembrod

[mering]

This version fails for us with the following error:

ERROR: no such package '@@[unknown repo 'com_google_googletest' requested from @@grpc+ (did you mean 'com_google_googleapis'?)]//': The repository '@@[unknown repo 'com_google_googletest' requested from @@grpc+ (did you mean 'com_google_googleapis'?)]' could not be resolved: No repository visible as '@com_google_googletest' from repository '@@grpc+'
ERROR: HOME/.cache/bazel/_bazel_USER/311480a20df1a9e749b4616bc4db69a0/external/grpc+/third_party/BUILD:68:6: no such package '@@[unknown repo 'com_google_googletest' requested from @@grpc+ (did you mean 'com_google_googleapis'?)]//': The repository '@@[unknown repo 'com_google_googletest' requested from @@grpc+ (did you mean 'com_google_googleapis'?)]' could not be resolved: No repository visible as '@com_google_googletest' from repository '@@grpc+' and referenced by '@@grpc+//third_party:gtest'

I am not completely sure where this comes from but it might be caused by the aliases in https://github.com/grpc/grpc/blob/master/third_party/BUILD. It might make sense to get rid of the aliases completely.

FYI: Related to grpc/grpc#38626 It might also be better to declare dependencies which are not needed by external repos depending on grpc as dev_dependency=True such that bazel build --enable_bzlmod //... works in the gRPC repo.

[meteorcloudy]

A bunch of bazel_dep were removed, see the diff against the previous version at https://github.com/bazelbuild/bazel-central-registry/actions/runs/13076495269/job/36489869601?pr=3671

Do you actually need to depend on @@grpc+//third_party:gtest?

It might also be better to declare dependencies which are not needed by external repos depending on grpc as dev_dependency=True

Agree, some bazel_deps should probably be dev_dependency instead of being removed completely.

[mering]

Do you actually need to depend on @@grpc+//third_party:gtest?

We directly depend on the following targets: //bazel:cc_grpc_library.bzl, //bazel:python_rules.bzl, //:grpc++, //:grpc++_reflection, //:grpc++_test, //:grpc_security_base, //:grpc_opencensus_plugin, //:src/python/grpcio/grpc:grpcio, //src/proto/grpc/health/v1:health_cc_proto, //src/proto/grpc/health/v1:health_cc_grpc.

From the //:grpc++_test target, we are using the following headers:

• grpcpp/test/default_reactor_test_peer.h
• grpcpp/test/server_context_test_spouse.h

[veblush]

So, looks like this is dynamic linking error caused by @grpc//examples/protos:helloworld_py_pb2_grpc, which transitively depends on @grpc//src/python/grpcio/grpc/_cython:cygrpc which is a pyx_library that requires all deps to be built as a dynamic library.

Thanks for your investigation and that makes sense. gRPC is not meant for DLL so seeing errors when building DLLs is expected. I'll disable that test on Windows.

[veblush]

FYI: Related to grpc/grpc#38626 It might also be better to declare dependencies which are not needed by external repos depending on grpc as dev_dependency=True such that bazel build --enable_bzlmod //... works in the gRPC

My ultimate goal is a full migration to bzlmod. However, this isn't possible until all dependencies are available in the BCR. Therefore, my current focus is on making the key public targets available through the gRPC BCR package.

[veblush]

It looks like grpcpp_gcp_observability target fails to build although it's passing in our repo using bzlmod. I just removed it from the presubmit test for now but it needs to be addressed in the future. Given that monitored_resource_cc_proto is claimed to be missing, I suspect that this might be relevant to switched_rules of googleapis (code).

bazel --nosystem_rc --nohome_rc build --announce_rc --verbose_failures -- @grpc//:grpcpp_gcp_observability
INFO: Reading rc options for 'build' from /usr/local/google/home/veblush/git/bazel-central-registry/temp_test_repos/grpc/1.70.1/anonymous_module/.bazelrc:
  'build' options: --enable_bzlmod --registry=file:///usr/local/google/home/veblush/git/bazel-central-registry
ERROR: /usr/local/google/home/veblush/.cache/bazel/_bazel_veblush/f4e55e1e7c6af5aea6ec923decdef74a/external/googleapis+/google/api/BUILD.bazel: no such target '@@googleapis+//google/api:monitored_resource_cc_proto': target 'monitored_resource_cc_proto' not declared in package 'google/api' defined by /usr/local/google/home/veblush/.cache/bazel/_bazel_veblush/f4e55e1e7c6af5aea6ec923decdef74a/external/googleapis+/google/api/BUILD.bazel (did you mean monitored_resource_proto, or monitored_resource.proto?)
ERROR: /usr/local/google/home/veblush/.cache/bazel/_bazel_veblush/f4e55e1e7c6af5aea6ec923decdef74a/external/grpc+/src/cpp/ext/gcp/BUILD:31:16: no such target '@@googleapis+//google/api:monitored_resource_cc_proto': target 'monitored_resource_cc_proto' not declared in package 'google/api' defined by /usr/local/google/home/veblush/.cache/bazel/_bazel_veblush/f4e55e1e7c6af5aea6ec923decdef74a/external/googleapis+/google/api/BUILD.bazel (did you mean monitored_resource_proto, or monitored_resource.proto?) and referenced by '@@grpc+//src/cpp/ext/gcp:observability'
ERROR: Analysis of target '@@grpc+//:grpcpp_gcp_observability' failed; build aborted: Analysis failed

[meteorcloudy]

Nice!