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?