STRIP_DEBUG_SYMBOLS placeholder breaks iOS cross-compilation with rules_foreign_cc

[andyf-canva]

The Apple CC toolchain in apple_support v1.24.1 contains a bug where the literal text "STRIP_DEBUG_SYMBOLS" is emitted as a linker flag instead of the actual flag -Wl,-S. This breaks iOS cross-compilation builds when using rules_foreign_cc.

Location

crosstool/cc_toolchain_config.bzl line 766:
https://github.com/bazelbuild/apple_support/blob/1.24.1/crosstool/cc_toolchain_config.bzl#L766

flag_group(
    flags = ["STRIP_DEBUG_SYMBOLS"],  # ❌ This is literal text, not a valid linker flag
    expand_if_available = "strip_debug_symbols",
),

Impact

When building rules_foreign_cc targets (like FFTW, OpenSSL) for iOS, the configure scripts test if the C compiler works. The linker receives invalid LDFLAGS:

LDFLAGS='-lc++ STRIP_DEBUG_SYMBOLS -headerpad_max_install_names'

The linker rejects STRIP_DEBUG_SYMBOLS as an unknown option, causing configure to fail with:

configure: error: C compiler cannot create executables

This completely blocks iOS cross-compilation for any project using rules_foreign_cc.

Expected Behavior

The flag should be the actual linker flag to strip debug symbols:

flag_group(
    flags = ["-Wl,-S"],  # ✅ Actual linker flag
    expand_if_available = "strip_debug_symbols",
),

Workaround

We're currently using a local patch as a workaround in our monorepo.

Environment

• apple_support version: 1.24.1
• Bazel version: 7.x
• Xcode version: 15.x+
• Platform: macOS building for iOS arm64

Reproduction

1. Set up a Bazel project with apple_support 1.24.1
2. Add a rules_foreign_cc target (e.g., FFTW)
3. Try to build for iOS: bazel build --config=apple //your:ios_target
4. Observe the configure failure

Would appreciate a fix in an upcoming release. Happy to submit a PR if helpful!

[keith]

hrm doesn't this mean that rules_foreign_cc isn't using the correct tool as the linker? as if it was using wrapped_clang this shouldn't be a problem?

[andyf-canva]

Good question! rules_foreign_cc is using the correct toolchain. The issue is that "STRIP_DEBUG_SYMBOLS" in line 766 is a literal string in the flags array, not a placeholder that gets expanded.

The expand_if_available attribute only controls conditional inclusion (include these flags if the build variable is set), not string substitution. So when symbol stripping is enabled, the toolchain literally adds "STRIP_DEBUG_SYMBOLS" to LDFLAGS, which then gets passed through ./configure scripts to the linker unchanged.

[keith]

yea that's all ok as long as LD=wrapped_clang, which i guess it needs to be since it can't be directly ld as the flags still expect the -Wl, prefix to be processed?

[keith]

fwiw i tested things over here bazel-contrib/rules_foreign_cc#1453 which builds c-ares for iOS and things built w/o issue, but maybe that's because it's a different rules_foreign_cc rule you're using? can you add a small sample project?

[novas0x2a]

I'm currently trying to fix other bugs in rules_foreign_cc, and in the process I upgraded apple_support (as a by-product of upgrading rules_rust), which then caused the examples repo to run into this problem, too, but only when bzlmod is enabled (it seems).

I'm still working on debugging, but if you wanted to take a look:

• Pipeline
• Code (note that I'm currently trying to work through all the bzlmod failures so I can enable it in CI, so there are multiple fixes in this branch currently)
• PR (though this is my active branch, so it might be changed by the time you see this, the above reference is HEAD as I write this, and is the version that was used with the above pipeline failure.)

I don't currently have a local darwin machine to test with (working on that...) and the CI doesn't save the logs we need (sigh) so I'm trying to psychically debug right now :|

I see in the log:

+ CC=/private/var/tmp/_bazel_buildkite/49f84be9037d8c1593e0ae3b67335929/sandbox/darwin-sandbox/1/execroot/_main/bazel-out/darwin_x86_64-opt-exec-ST-d57f47055a04/bin/external/apple_support~/crosstool/wrapped_clang
+ LD=/private/var/tmp/_bazel_buildkite/49f84be9037d8c1593e0ae3b67335929/sandbox/darwin-sandbox/1/execroot/_main/bazel-out/darwin_x86_64-opt-exec-ST-d57f47055a04/bin/external/apple_support~/crosstool/cc_wrapper.sh
+ LDFLAGS='-lc++ -Wl,-oso_prefix,__BAZEL_EXECUTION_ROOT__/ STRIP_DEBUG_SYMBOLS -headerpad_max_install_names -no-canonical-prefixes -target x86_64-apple-macosx15.2 -fobjc-link-runtime -dead_strip -framework Foundation -Wl,-no_warn_duplicate_libraries -undefined error'

• CC is set to wrapped_clang
• LD is set to a different wrapper (cc_wrapper.sh)
• LDFLAGS has the raw string STRIP_DEBUG_SYMBOLS

[novas0x2a]

Oh, I lied, I found a darwin machine. Hmm:

configure:4313: /private/var/tmp/_bazel_mlundy/642f356a53fac1e882fad3f5797eb132/sandbox/darwin-sandbox/6/execroot/_main/bazel-out/darwin_x86_64-opt-exec-ST-d57f47055a04/bin/external/apple_support~/crosstool/wrapped_clang -D_FORTIFY_SOURCE=1 -fstack-protector -fcolor-diagnostics -Wall -Wthread-safety -Wself-assign -fno-omit-frame-pointer -g0 -O2 -DNDEBUG -DNS_BLOCK_ASSERTIONS=1 -fdebug-prefix-map=__BAZEL_EXECUTION_ROOT__=. -fdebug-prefix-map=__BAZEL_XCODE_DEVELOPER_DIR__=/PLACEHOLDER_DEVELOPER_DIR -isysroot __BAZEL_XCODE_SDKROOT__ -F__BAZEL_XCODE_SDKROOT__/System/Library/Frameworks -F__BAZEL_XCODE_DEVELOPER_DIR__/Platforms/MacOSX.platform/Developer/Library/Frameworks -no-canonical-prefixes -target x86_64-apple-macosx14.5 -Wno-builtin-macro-redefined -D__DATE__=\\"redacted\\" -D__TIMESTAMP__=\\"redacted\\" -D__TIME__=\\"redacted\\"  -lc++ -Wl,-oso_prefix,__BAZEL_EXECUTION_ROOT__/ STRIP_DEBUG_SYMBOLS -headerpad_max_install_names -no-canonical-prefixes -target x86_64-apple-macosx14.5 -fobjc-link-runtime -dead_strip -framework Foundation -Wl,-no_warn_duplicate_libraries -undefined error conftest.c  >&5
ld: warning: -undefined error is deprecated
ld: warning: -undefined error is deprecated
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: can't open file:  (No such file or directory)
Error in child process '/usr/bin/xcrun'. 1
configure:4317: $? = 2
configure:4357: result: no

It's executing the correct CC, but then getting an error on executing strip?

[novas0x2a]

Oh, it's 218e193, isn't it? Let's find out.

[novas0x2a]

Yep; that was the problem (in my case). @andyf-canva not sure if this was also the same problem you had, but if it was, I'll probably (... assuming nothing else is broken) land my PR soon.

[keith]

cc_wrapper.sh is a bit weird, but yea that ends up calling wrapped_clang too:

apple_support/crosstool/osx_cc_wrapper.sh.tpl

Lines 68 to 72 in 8f331d8

	# wrapped_clang uses the path it's called as to relativize paths, so we cannot
	# call it using an absolute path
	script_path="$(cd "$(/usr/bin/dirname "${BASH_SOURCE[0]}")" && pwd)"
	relative_script_path=${script_path##*"$(pwd)"/}
	"$relative_script_path"/wrapped_clang "$@"

so once you updated past that fix your repro case worked right?

[novas0x2a]

yeah, I upgraded from 1.24.1 to 1.24.5 (though I'm guessing 1.24.3 would have been fine) and the problem went away; it looks like the compiler checks that autotools run don't bother to set -o.

[keith]

Thanks. Let me know if you hit another case!