Skip to content

Conversation

shivaspeaks
Copy link
Member

@shivaspeaks shivaspeaks commented Aug 28, 2025

Fixes #7690

VERIFIED:

./buildscripts/kokoro/macos.sh 
...
...
BUILD SUCCESSFUL
lipo -archs $(find ./mvn-artifacts -name "protoc-gen-grpc-java-*-osx-aarch_64.exe")

x86_64 arm64

@shivaspeaks shivaspeaks changed the title add support for aarch64 add support for macos aarch64 Aug 28, 2025
@@ -46,6 +46,11 @@ else
-DCMAKE_CXX_STANDARD=14 -Dprotobuf_BUILD_TESTS=OFF -DBUILD_SHARED_LIBS=OFF \
-DCMAKE_INSTALL_PREFIX="$INSTALL_DIR" -DABSL_INTERNAL_AT_LEAST_CXX17=0 \
-B. || exit 1
elif [[ "$ARCH" == "aarch_64" && "$(uname -s)" == "Darwin" ]]; then
cmake .. \
-DCMAKE_CXX_STANDARD=14 -Dprotobuf_BUILD_TESTS=OFF -DBUILD_SHARED_LIBS=OFF \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eric's comment said we need to pass both arm64 and x86_64 to get the universal binary. Are you getting the x86 binary?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm avoiding the cross-compilation here that Eric mentioned. Each binary is built natively on its target hardware, which is simpler. This is the alternate way to support in arm64.
The existing Kokoro job (macos.cfg) will continue to run on an x86_64 machine and produce a pure osx-x86_64 binary. The new job I've added (macos_aarch64.cfg) will run in parallel on a native aarch64 (Apple Silicon) machine and produce a pure osx-aarch_64 binary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, by keeping the builds separate, we de-risk the change and ensure the existing x86_64 build process remains completely untouched and stable.

Copy link
Member

@ejona86 ejona86 Aug 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem you have to consider with this approach is if we build on Sequoia, then the binary is only guaranteed to work on Sequoia and newer OS X versions. So we need to build on the oldest version of OS X that is supported.

Right now we're using Ventura and our CI doesn't have an ARM Ventura. However, we can wait some weeks, and Apple tends to drop OS X support in September/October/November, at which point we'd support Sonoma. We do have Sonoma available for ARM and x86. But after that with Sequoia we're going to have the opposite problem, of still wanting to support x86 but only having an ARM CI. That leaves us in a bind with Sequoia and Tahoe, which both still support x86 hardware (Tahoe will be the last to support x86).

Copy link
Member Author

@shivaspeaks shivaspeaks Sep 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, to mitigate these problems I tried with the original idea that Eric proposed—having universal binaries. Take a look!

@shivaspeaks shivaspeaks requested a review from ejona86 August 28, 2025 15:53
@shivaspeaks shivaspeaks marked this pull request as ready for review August 28, 2025 15:53
export -n JAVA_HOME
export PATH="$(/usr/libexec/java_home -v"1.8.0")/bin:${PATH}"

export ARCH=aarch_64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes me uneasy. We're having two builds but assuming the machine they are running on, and it isn't obvious from the pool names which machine type is which. We can do that, but it is probably clearer/better to detect the machine type and then choose the ARCH to match?

@@ -46,6 +46,11 @@ else
-DCMAKE_CXX_STANDARD=14 -Dprotobuf_BUILD_TESTS=OFF -DBUILD_SHARED_LIBS=OFF \
-DCMAKE_INSTALL_PREFIX="$INSTALL_DIR" -DABSL_INTERNAL_AT_LEAST_CXX17=0 \
-B. || exit 1
elif [[ "$ARCH" == "aarch_64" && "$(uname -s)" == "Darwin" ]]; then
cmake .. \
-DCMAKE_CXX_STANDARD=14 -Dprotobuf_BUILD_TESTS=OFF -DBUILD_SHARED_LIBS=OFF \
Copy link
Member

@ejona86 ejona86 Aug 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem you have to consider with this approach is if we build on Sequoia, then the binary is only guaranteed to work on Sequoia and newer OS X versions. So we need to build on the oldest version of OS X that is supported.

Right now we're using Ventura and our CI doesn't have an ARM Ventura. However, we can wait some weeks, and Apple tends to drop OS X support in September/October/November, at which point we'd support Sonoma. We do have Sonoma available for ARM and x86. But after that with Sequoia we're going to have the opposite problem, of still wanting to support x86 but only having an ARM CI. That leaves us in a bind with Sequoia and Tahoe, which both still support x86 hardware (Tahoe will be the last to support x86).

@@ -41,7 +41,12 @@ else
mkdir "$DOWNLOAD_DIR/protobuf-${PROTOBUF_VERSION}/build"
pushd "$DOWNLOAD_DIR/protobuf-${PROTOBUF_VERSION}/build"
# install here so we don't need sudo
if [[ "$ARCH" == x86* ]]; then
if [[ "$(uname -s)" == "Darwin" ]]; then
cmake .. \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unindent this line two spaces. It shouldn't be at the same level as the next line as that's a line continuation.

@@ -42,8 +42,6 @@ LOCAL_OTHER_ARTIFACTS="$KOKORO_GFILE_DIR"/github/grpc-java/artifacts/

# from macos job:
[[ "$(find "$LOCAL_MVN_ARTIFACTS" -type f -iname 'protoc-gen-grpc-java-*-osx-x86_64.exe' | wc -l)" != '0' ]]
# copy all x86 artifacts to aarch until native artifacts are built
find "$LOCAL_MVN_ARTIFACTS" -type f -iname 'protoc-gen-grpc-java-*-osx-x86_64.exe*' -exec bash -c 'cp "${0}" "${0/x86/aarch}"' {} \;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we still need this line?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we're building a single universal binary for macOS, isn't this copy obsolete?

GRADLE_FLAGS+=" -PbuildUniversal=true"
else
# For Linux, build for a single, specific architecture.
GRADLE_FLAGS+=" -PtargetArch=$ARCH"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that targetArch has a default in the build.gradle when it isn't specified. So avoiding this line for Mac doesn't do much.

@@ -103,6 +103,10 @@ model {
cppCompiler.args "--std=c++14"
addEnvArgs("CXXFLAGS", cppCompiler.args)
addEnvArgs("CPPFLAGS", cppCompiler.args)
if (project.hasProperty('buildUniversal') && osdetector.os == "osx") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

-PbuildUniversal=false will be true here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

protoc-gen-grpc-java not available on apple m1
3 participants