Description of the bug:

When attempting to build a C++ target (say, @zlib//:zlib, as part of protobuf) with Bazel 6.5.0 on Tahoe, the wrapped_clang from @bazel_tools fails due to a missing LC_UUID symbol:

dyld[93381]: missing LC_UUID load command in external/local_config_cc/wrapped_clang

Granted, this is by now a very old Bazel, and macOS Tahoe 26.0 is very new; not a likely combination in general. I don't expect there to be a Bazel 6 update to fix this, but I wanted to get this on the record in case anyone else hits it. I discovered it while developing the "Bzlmod Migration Bootcamp" example for BazelCon 2025, which is a very specific and unusual use case.

Which category does this issue belong to?

C++ Rules

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

$ mkdir wrapped_clang-lc_uuid-macos_tahoe-repro
$ cd !$
$ cat > MODULE.bazel
module(name = "wrapped_clang-lc_uuid-macos_tahoe-repro")
bazel_dep(name = "zlib", version = "1.3.1.bcr.7")

$ USE_BAZEL_VERSION=6.5.0 bazel build --enable_bzlmod @zlib//:zlib

ERROR: external/zlib~1.3.1.bcr.7/BUILD.bazel:91:11:
  Compiling inflate.c failed: (Aborted): wrapped_clang failed:
  error executing command (from target @zlib~1.3.1.bcr.7//:z)
  external/bazel_tools~cc_configure_extension~local_config_cc/wrapped_clang
    '-D_FORTIFY_SOURCE=1' -fstack-protector -fcolor-diagnostics -Wall
    -Wthread-safety -Wself-assign -fno-omit-frame-pointer -O0 ...
    (remaining 34 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain 
the sandbox build root for debugging

dyld[94091]: missing LC_UUID load command in
  external/bazel_tools~cc_configure_extension~local_config_cc/wrapped_clang
dyld[94091]: missing LC_UUID load command

Which operating system are you running Bazel on?

macOS Tahoe 26.0

What is the output of bazel info release?

release 6.5.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

No response

Have you found anything relevant by searching the web?

The only definitive hit I found on the web was from the following twitter comment:

Peter Steinberger
@steipete
Heads up: If you see macOS 26 throwing “missing LC_UUID” at launch, then your fat binary was stripped of its UUID. Re-build with latest Xcode or add -Xlinker -random_uuid (and strip with strip -Sxu) so LC_UUID stays in each arch.

Seems Tahoe is stricter at enforcing this.
6:16 PM · Jul 3, 2025

Any other information, logs, or outputs that you want to share?

This doesn't happen with Bazel 7 or later, since its @bazel_tools no longer includes the 'wrapped_clang' binary.

Trying to use apple_support and rules_cc explicitly didn't seem to help. Updating MODULE.bazel to the following produces the same result (where apple_support 1.20.0 is the last version compatible with Bazel 6):

# MODULE.bazel
module(name = "wrapped_clang-lc_uuid-macos_tahoe-repro")
bazel_dep(name = "apple_support", version = "1.20.0")
bazel_dep(name = "rules_cc", version = "0.2.8")
bazel_dep(name = "zlib", version = "1.3.1.bcr.7")