Remove uses_cxx11()in build.rs build_grpc function causing MacOS build failures

[taddes]

Describe the bug
When attempting to compile and build several rust projects on MacOS (Silicon and otherwise), a regression became apparent when the build would fail when reaching grpc-rs:

error: failed to run custom build command for grpcio-sys v0.13.0+1.56.2-patched, due to error occurred in cc-rs: unknown target aarch64-apple-darwin11.

followed by:

error occurred in cc-rs: unknown target aarch64-apple-darwin11.

(See further below for full error output)

This pointed to the problematic code in build.rs here. We set up a workaround after a lot of debugging, we pulled down a local copy of grpc-rs and simply called config.build() instead of config.uses_cxx11().build() and altered our Cargo.toml like so to point to the local build:

[patch.crates-io]
grpcio-sys = { path = "/path/to/grpc-rs/grpc-sys" }

This is definitely a workout and not a sustainable solution. This functionality is not really needed given minimum suppored OS versions in rust are well above MacOS 10.7 and cc sets the value in the deployment target. Modifying the returned value like this results in confusion and potential problems downstream.

See additional context section, as this issue was relatedly discussed in cc-rs and ties directly into this bug. They just landed a patch related to this.

To Reproduce
Steps to reproduce the behavior:

1. Attempt to build cargo build (on Intel or Silicon Mac) with versions listed below. One example repo was autopush-rs

Expected behavior
Build should not fail when compiling and reaching grpcio-sys.

System information

• CPU architecture: MacOS Silicon, Apple M1 Max
• Distribution and kernel version: 14.6.1 (23G93) - Sonoma
• Any other system details we should know?:
  rustc/cargo 1.84.1

grpcio = { version = "=0.13.0", features = ["openssl"], optional = true }
grpcio-sys = { version = "=0.13.0", optional = true }

Additional context

See related in cc-rs with recent PR to bypass and deprecate uses_cxx11

Previously, a workaround had been introduced to fix a regression default targets on OSX, which is now no longer needed. As stated in 1276's comments, this is redundant nowadays, where:

1. The minimum supported OS version in Rust is way above macOS 10.7
   2. cc sets this value in the deployment target.

And wrong because the target value in cc is the rustc target, while cmake invalidly assumed it refers to the Clang target.

full error output

Caused by:
  process didn't exit successfully: `/Users/taddeskorris/Documents/code/mozilla/autopush-rs/target/debug/build/grpcio-sys-08498d5bf74a3ea3/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-changed=grpc_wrap.cc
  cargo:rerun-if-changed=grpc
  cargo:rerun-if-env-changed=CARGO_CFG_TARGET_OS
  cargo:rerun-if-env-changed=GRPCIO_SYS_USE_PKG_CONFIG
  cargo:rerun-if-env-changed=CARGO_CFG_TARGET_OS
  cargo:rustc-link-lib=resolv
  cargo:rerun-if-env-changed=CARGO_CFG_TARGET_OS
  cargo:rustc-link-lib=framework=CoreFoundation
  cargo:rerun-if-env-changed=CXX
  OPT_LEVEL = Some(0)
  OUT_DIR = Some(/Users/taddeskorris/Documents/code/mozilla/autopush-rs/target/debug/build/grpcio-sys-2a0bb54230892aea/out)
  TARGET = Some(aarch64-apple-darwin)
  HOST = Some(aarch64-apple-darwin)
  cargo:rerun-if-env-changed=CC_aarch64-apple-darwin
  CC_aarch64-apple-darwin = None
  cargo:rerun-if-env-changed=CC_aarch64_apple_darwin
  CC_aarch64_apple_darwin = None
  cargo:rerun-if-env-changed=HOST_CC
  HOST_CC = None
  cargo:rerun-if-env-changed=CC
  CC = None
  cargo:rerun-if-env-changed=CC_ENABLE_DEBUG_OUTPUT
  RUSTC_WRAPPER = None
  cargo:rerun-if-env-changed=CRATE_CC_NO_DEFAULTS
  CRATE_CC_NO_DEFAULTS = None
  DEBUG = Some(true)
  cargo:rerun-if-env-changed=MACOSX_DEPLOYMENT_TARGET
  MACOSX_DEPLOYMENT_TARGET = None
  cargo:rerun-if-env-changed=CFLAGS_aarch64-apple-darwin
  CFLAGS_aarch64-apple-darwin = None
  cargo:rerun-if-env-changed=CFLAGS_aarch64_apple_darwin
  CFLAGS_aarch64_apple_darwin = None
  cargo:rerun-if-env-changed=HOST_CFLAGS
  HOST_CFLAGS = None
  cargo:rerun-if-env-changed=CFLAGS
  CFLAGS = None
  CARGO_ENCODED_RUSTFLAGS = Some()
  cargo:rustc-link-search=native=/Users/taddeskorris/Documents/code/mozilla/autopush-rs/target/debug/build/libz-sys-de390d0a5dd9c503/out/build
  cargo:rustc-link-search=native=/Users/taddeskorris/Documents/code/mozilla/autopush-rs/target/debug/build/libz-sys-de390d0a5dd9c503/out/lib
  CMAKE_TOOLCHAIN_FILE_aarch64-apple-darwin = None
  CMAKE_TOOLCHAIN_FILE_aarch64_apple_darwin = None
  HOST_CMAKE_TOOLCHAIN_FILE = None
  CMAKE_TOOLCHAIN_FILE = None
  CMAKE_GENERATOR_aarch64-apple-darwin = None
  CMAKE_GENERATOR_aarch64_apple_darwin = None
  HOST_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None

  --- stderr


  error occurred in cc-rs: unknown target aarch64-apple-darwin11.

  NOTE: `cc-rs` only supports a fixed set of targets when not in a build script.
  - If adding a new target, you will need to fork of `cc-rs` until the target
    has landed on nightly and the auto-generated list has been updated. See also
    the `rustc` dev guide on adding a new target:
    https://rustc-dev-guide.rust-lang.org/building/new-target.html
  - If using a custom target, prefer to upstream it to `rustc` if possible,
    otherwise open an issue with `cc-rs`:
    https://github.com/rust-lang/cc-rs/issues/new```

[BusyJay]

I see. So the fix is to just remove the line that uses_cxx11, right? Would you like to send a PR for this?

[taddes]

@BusyJay exactly! Thank you for your quick response. I'll gladly submit a PR for this.

[taddes]

Is it preferred that I fork the repo and submit a PR for review, or should I request access to be able to push a new branch to master? Thanks

[BusyJay]

It seems a PR is submitted: #655

[taddes]

I see the PR was submitted but changes haven't landed yet. Were you going to still have that PR land with the contributor making the chances, or can/shall I? Would love to pull out the workarounds we have at present. Thanks @BusyJay