This commit does the following 3 things for Android bazel rules, which depends on each other
1. Update NDK to 26.2.11394342 (and a few other Android things)
2. Use rules_android_ndk instead of builtin `native.android_ndk_repository`
* `third_party/android/android_configure.bzl` was a workaround for users who don't set `$ANDROID_NDK_HOME` env var. Now with rules_android_ndk, we can declare repo without registering the toolchain. Instead users who need NDK toolchain should use `--extra_toolchains` to manually register the toolchain, as shown in README.md.
3. Migrate to platforms. See https://bazel.build/concepts/platforms
* Currently we declares android platforms that is needed for binder transport APK. Later gRPC repo can gradually migrate to platforms for other platforms.
* The value of `crosstool_top` will still be `//external:android/crosstool` (which is the default value), so existings android `config_settings` will still work. We should migrate them to match with `@platforms//os:android` constraint later.
The platforms migration needs Bazel 7.0 to work so we also override bazel version in testing scripts.
Closes#36116
PiperOrigin-RevId: 617244655
`GPR_BACKWARDS_COMPATIBILITY_MODE` was devised to support old Linux kernel with old glibc but gRPC is now expected to support glibc 2.17 and later (2.17 is derived from the oldest but supported Linux distro, CentOS 7). Effectively, gRPC doesn't need `GPR_BACKWARDS_COMPATIBILITY_MODE` anymore. Hence, let's remove it.
gRPC Python and Ruby that distribute binary artifacts already began to use `manylinux` environment dealing with this issue in a better way so they don't need this flag anymore.
Closes#35602
PiperOrigin-RevId: 599895270
Some minor changes for the platform:
* `sys/types.h` needs to be included before `netinet/tcp.h` to provide
definitions for `u_int8_t`, `u_int16_t`, and `u_int32_t`.
* cares has an OpenBSD-specific config header but is not actually hooked
up in cares.BUILD. Remedy that.
This fixes Bazel selecting the wrong source for `cares` when building
with `--cpu=darwin_arm64` or `--cpu=darwin_arm64e` (it was selecting the
source in the default condition, which is for Linux).
We're having the same patch in Bazel
(1782f0ae75;
it was using an older grpc release). Fixing this here so we can remove
the patch in the next update.
This change adds `ares_android.h` and `ares_android.c` to the `third_party/cares/cares.BUILD` in order to support builds in the Android Native Development Kit (NDK).
Fixes grpc#21437
genrules are not supported on Windows without
an msys bash installation, which is an undesirable
dependency. Fortunately we can use skylib's copy_file
to accomplish the same thing as the genrules were doing.
release notes: no
This fixes the issue: https://github.com/grpc/grpc/issues/16688
Which causes that grpc can not be build because of the following
compiler error:
third_party/cares/cares/ares_init.c: In function ‘ares_dup’:
third_party/cares/cares/ares_init.c:301:17: error: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Werror=sizeof-pointer- memaccess] sizeof(src->local_dev_name));
Bazel recognizes both "darwin" and "darwin_x86_64" as CPU values, and
the Apple Bazel rules currently recommend the latter for building
macOS targets. Until this is cleaned up, this change allows grpc to
build correctly when that configuration is used.
Fixes#17649.
For ios build, bazel build needs to be invoked with:
--ios_multi_cpu=armv7,arm64 build. This in turn gets picked as
cpu based on the docs:
--[no]experimental_enable_objc_cc_deps default: "true"
Allows objc_* rules to depend on cc_library and causes any objc dependencies to be built with --cpu set to "ios_<--ios_cpu>" for any values in --ios_multi_cpu.
This diff explicitly adds darwin config for cpu being ios_x86_64, ios_armv7,
ios_armv7s and ios_arm64. We cant use ios_cpu as condition because its set to x86_64
by default and causes linux build break.
The WORKSPACE file now pulls third_party dependencies directly instead of requiring a git submodule init and update.
The git hashes pulled by Bazel are exactly the same as the git submodules checked into third_party.
A tiny bit of complexity comes from the c-ares project's use of ares_config.h.cmake and ares_build.c.cmake.
The current solution to this problem is to check in a valid ares_config.h and a few valid ares_config.h files.
This is the same general approach used still, but ares_config.h and ares_build.h are supplied to cares.BUILD
from the only remaining local_repository, which serves only to export these two header files.
- Update CMakeLists.txt (original template and generated code)
to prevent forcefully linking `dl` on all UNIX platforms,
and rely on `${CMAKE_DL_LIBS}` portable variable instead.
- Do not try linking against `librt` on macOS.
- Add a `config_freebsd` directory containing the header file
generated by the `configure` script for the `ares` library.
Ming-Chuan