This should be able to unblock using grpc on vision os, will add tests later
Closes#36476
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36476 from HannahShiSFB:support-visionos edbde32d23
PiperOrigin-RevId: 630173448
#35923 removed the use of mach_absolute_time in gpr.
There is still one usage in protobuf, which they have removed the usage in https://github.com/protocolbuffers/protobuf/pull/15554 but we haven't update yet.
However gRPC library does not depends on protobuf but upb, so we should no longer need NSPrivacyAccessedAPICategorySystemBootTime any more.
Closes#36080
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36080 from HannahShiSFB:remove-privacy-for-mach_absolute_time dacccafeec
PiperOrigin-RevId: 617995787
Change was created by the release automation script. See go/grpc-release.
Additional Changes:
* Boring SSL started to [Require SSE2 when targetting 32-bit x86](56d3ad9d23), thus added `-msse2` to fix some build failures.
Closes#36089
PiperOrigin-RevId: 614822548
Change was created by the release automation script. See go/grpc-release.
On top of changes made by the script, `setup.py` had to be updated to have `/std:c11` option for MSVC to use c11 features for boringssl.
Closes#35768
PiperOrigin-RevId: 603403329
BoringSSL-GRPC uses sources from https://github.com/google/boringssl.git, which doesn't contain PrivacyInfo.xcprivacy file.
This PR embeds the manifest data into the podspec and extract during pod install, similar to file boringssl_prefix_symbols.h
--
Will need to regenerate the podspec after #35542 merged.
Closes#35616
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35616 from HannahShiSFB:privacy-manifests-boring-ssl d068be244b
PiperOrigin-RevId: 601274520
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Follow-up to add privacy manifests to #35042
- [x] Update podspec template files
- [x] Align on manifest update:
```
git grep mach_absolute_time
src/core/lib/gpr/posix/time.cc:static uint64_t g_time_start = mach_absolute_time();
src/core/lib/gpr/posix/time.cc: ((double)(mach_absolute_time() - g_time_start)) * g_time_scale;
```
cc: @paulb777
Closes#35542
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35542 from ncooke3:nc/privacy-manifests b0e0e57d2e
PiperOrigin-RevId: 600595032
Upgrade apple platform deployment_target versions to fix the cocoapods
push of BoringSSL-GRPC about the following error:
```
ld: file not found: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/arc/libarclite_macosx.a
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
ref: https://developer.apple.com/forums/thread/725300
This also aligns with the versions required by
[protobuf](https://github.com/protocolbuffers/protobuf/pull/10652)
```
ios.deployment_target = '10.0'
osx.deployment_target = '10.12'
tvos.deployment_target = '12.0'
watchos.deployment_target = '6.0'
```
Upgrade boringssl to the latest "master-with-bazel"
- use the `'USE_HEADERMAP' => 'NO'` fix for ObjC
- update the key for asm optimizations on mac/apple in python's setup.py
This PR depends on monterey fixes here:
https://github.com/grpc/grpc/pull/32493 and the boringssl's build
simplification
https://boringssl-review.googlesource.com/c/boringssl/+/56465.
---------
Co-authored-by: Hannah Shi <hannahshisfb@gmail.com>
Make remaining objC jobs compatible with kokoro monterey workers and
prepare for boringssl upgrade.
The changes here are taken from https://github.com/grpc/grpc/pull/32357,
but they should be merged in a separate PR
(we need the changes to be able to upgrade to monterey anyway and
there's no reason to make the boringssl upgrade PR more complicated by
bundling more fixes into it).
I've checked that the grpc_basictests_objc_examples and
grpc_ios_binary_size are green if switched to monterey.
Unfortunately it's hard to make grpc_basictests_objc_examples pass on
both monterey and mojave, so I suggest merging this PR at the same time
as CL to upgrade the kokoro jobs to monterey.
- that way both PR and continuous runs will remain green
- older branches would need a backport anyway
---------
Co-authored-by: Hannah Shi <hannahshisfb@gmail.com>
This enforces entire script to exit with error if any of the
pre-install command fails. The error exit marks the pod install
as failure and therefore prompting user's immediate attention.
Previoulsy pre-install script might siliently fail partially and
left corrupted cocoapod cahce which causes a number of build issues
during version upgrade
Xuan Wang