Also strip Swift symbols when --objc_enable_binary_stripping is passed

[thii]

Resolves https://github.com/bazelbuild/bazel/issues/13122

[jin]

cc @trybka

[allevato]

I'll defer to @trybka on this one. We've discussed in the past that this flag is fundamentally broken because it conflates two meanings of "strip" (symbols and dead code stripping) and has other side effects on top of that; I'm not sure if adding more behavior to this already broken flag is the right thing to do or if it would have other undesirable side effects.

[DavidGoldman]

Would it make sense to file a radar/feedback for what API we would need from strip?

[allevato]

Would it make sense to file a radar/feedback for what API we would need from strip?

Not sure I follow. When I say "this flag" I'm referring to --objc_enable_binary_stripping—I don't see anything here that needs Apple's attention. The problem is the single flag in Bazel that combines too many unrelated behaviors, and this PR would add more behavior to that.

[trybka]

+cc @jyknight

[trybka]

--objc_enable_binary_stripping is a confusing flag that conflates at least two meanings of "strip" and also has other side effects. Dead code elimination happens at link time, and a debugging symbol strip action is registered for final executable links.

We'd like to eliminate it altogether, but there are some... complications. I'm going to look into externalizing an internal doc I have on the matter to provide additional context. As such, I'm hesitant to add more meaning to it (i.e. having it affect Swift, too).

It's not clear what exactly to do here--but I think that the hard-coded action created by the ObjC rules should go away.

-x might be fine, but in practice doesn't remove most symbols, because they are all defaulted to dynamically exported.

[keith]

If this isn't the right path I wonder if we should make --stripopt or something apply to this strip logic too so folks can do something to solve this

[trybka]

https://github.com/trybka/scraps/blob/master/Apple_Stripping.md

[trybka]

I think it would be sensible to make this register a strip action like cc_binary does, and then the options can be configured in the Crosstool.

[steeve]

Jumping on this, emergetools.com actually recommends -rSTx -no_code_signature_warning for all binaries.

[keith]

Please checkout https://github.com/bazelbuild/bazel/pull/14951

[keertk]

Hi @googlewalt, was doing some checks of unmerged PRs and wanted to see if this one is still needed and good to be approved/merged internally?

[thii]

Closing in favor of a more proper solution at https://github.com/bazelbuild/bazel/pull/14951.