I've gotten around the platform mapping issues by symlinking the envoy envoy/bazel directory into this project, but have encountered something that seems to look like macos options aren't propagating down:
(16:28:05) ERROR: /Users/alecholmes/Developer/greymatter-io/gm-proxy2/BUILD:12:16: Linking gm-proxy failed: (Aborted): cc_wrapper.sh failed: error executing command external/local_config_cc/cc_wrapper.sh @bazel-out/darwin_arm64-fastbuild/bin/gm-proxy-2.params
Use --sandbox_debug to see verbose messages from the sandbox
ld: unknown option: -E
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error in child process '/usr/bin/xcrun'. 1
external/local_config_cc/cc_wrapper.sh: line 69: 93349 Abort trap: 6 "$(/usr/bin/dirname "$0")"/wrapped_clang "$@"
Target //:gm-proxy failed to build
Use --verbose_failures to see the command lines of failed build steps.
(16:28:05) INFO: Elapsed time: 765.193s, Critical Path: 70.01s
(16:28:05) INFO: 7972 processes: 1797 internal, 6174 darwin-sandbox, 1 worker.
(16:28:05) FAILED: Build did NOT complete successfully
From what it seems is like options are being passed to a mac os specific linker that should only be on the linux side of things. I'm wondering if this is just the bazel setup.
My bazelrc looks like the following:
import %workspace%/envoy/.bazelrc
# overrides
build --copt=-Wno-unknown-warning-option
# current patch for building on M1 machines:
# https://github.com/envoyproxy/envoy/pull/20889/files
build:macos --define wasm=disabled
# terminal ux
common --curses=yes
build --noprogress_in_terminal_title
build --show_task_finish
build --show_timestamps
build --worker_verbose
test --noprogress_in_terminal_title
test --noshow_loading_progress
test --show_task_finish
test --show_timestamps
test --worker_verbose
My LD and clang info:
$ which ld
/usr/bin/ld
$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-762
BUILD 12:49:08 Mar 30 2022
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 13.1.6, (clang-1316.0.21.2.3) (static support for 28, runtime is 28)
TAPI support using: Apple TAPI version 13.1.6 (tapi-1316.0.7.3)
$ which clang
/opt/homebrew/opt/llvm/bin/clang
$ clang -v
Homebrew clang version 13.0.1
Target: arm64-apple-darwin21.4.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
I've gotten around the platform mapping issues by symlinking the envoy
envoy/bazel
directory into this project, but have encountered something that seems to look like macos options aren't propagating down:From what it seems is like options are being passed to a mac os specific linker that should only be on the linux side of things. I'm wondering if this is just the bazel setup.
My bazelrc looks like the following:
My LD and clang info:
ENV: