[msbuild] Strip binding-embedded dynamic frameworks with 'strip -S -x'. Fixes #25952.#25970
[msbuild] Strip binding-embedded dynamic frameworks with 'strip -S -x'. Fixes #25952.#25970rolfbjarne wants to merge 1 commit into
Conversation
Fixes #25952. A Release build of an app that references a binding project with an embedded dynamic framework failed with: strip: error: symbols referenced by indirect symbol table entries that can't be stripped in: .../CameraFramework.framework/CameraFramework The SymbolStrip task only passes '-S -x' to strip (to strip just debug/local symbols) when an item's 'Kind' metadata is 'Framework'/'Dynamic' (or the path ends in '.dylib'); otherwise it does a full strip, which fails for a dynamic library that references undefined symbols (objc_msgSend, ...) via the indirect symbol table. This regressed in commit 6b9cfc9 ("[msbuild] Filter static frameworks from post-processing items. Fixes #24840.", #24845), which changed the framework post-processing item in Xamarin.Shared.targets from: <_PostProcessingItem Include="@(_ResolvedNativeReference->'...')" Condition="'%(Kind)' == 'Framework'"> to: <_PostProcessingItem Include="@(_FilteredFrameworkToPublish->'...')"> `@(_ResolvedNativeReference)` carried the `Kind=Framework+ metadata (as the removed condition shows), but `@(_FilteredFrameworkToPublish)` does not, so the metadata was silently lost. Frameworks embedded in a binding project are extracted by the linker without 'Kind' metadata, so they reached the SymbolStrip task with an empty 'Kind' and got a full strip. Apps that use a direct `<NativeReference Kind="Framework">` are not affected (the Kind flows through); only binding-embedded frameworks are. Fix this in two places: * Set `Kind=Framework` on the framework _PostProcessingItem (the block only ever contains frameworks), restoring the metadata the SymbolStrip task relies on. * Also detect frameworks by path in the SymbolStrip task (an item inside a '.framework' directory), mirroring the existing '.dylib' fallback, so a full strip is never done on a framework even if the 'Kind' metadata is missing. Also add a test (StripEmbeddedDynamicFramework) that builds an app which references a binding project that embeds a dynamic framework (NoBindingEmbedding=false) with symbol stripping enabled, and asserts the build succeeds. Without the fix this fails at the strip step. The test builds in Release (so the linker extracts the framework into the post-processing path), with a single RuntimeIdentifier (frameworks aren't post-processed in multi-RID builds) and NoSymbolStrip=false (so the framework is stripped even for the simulator). The existing binding projects that embed a framework only embed static libraries (as frameworks), which are filtered out and never copied to the app (so never stripped). The one project that embeds a dynamic framework (EmbeddedFrameworkInBindingProjectApp, which embeds XTest.framework) didn't hit the problem, because XTest.framework (built from libframework.m) doesn't call any external functions and so can be fully stripped. Make libframework.m send an Objective-C message so the framework binary imports an Objective-C runtime function referenced via the indirect symbol table; such a binary can't be fully stripped, so the test now exercises the strip code path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Pull request overview
This PR fixes a regression in the MSBuild post-processing pipeline where binding-embedded dynamic frameworks could be fully stripped (instead of debug-symbol-only stripped), causing strip to fail for frameworks that import undefined symbols (e.g. Objective-C runtime symbols). It also adds a regression test to ensure apps referencing binding-embedded dynamic frameworks build successfully with symbol stripping enabled.
Changes:
- Restore
Kind=Frameworkmetadata on framework_PostProcessingItementries so theSymbolStriptask usesstrip -S -x. - Add a
SymbolStripfallback that detects framework executables by path even ifKindmetadata is missing. - Extend the test framework implementation and add a new unit test that validates the build succeeds when stripping an embedded dynamic framework.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| tests/test-libraries/libframework.m | Forces the test framework binary to import Objective-C runtime symbols so a full strip would fail, exercising the regression. |
| tests/dotnet/UnitTests/ProjectTest.cs | Adds a regression test that builds an app referencing a binding-embedded dynamic framework with stripping enabled. |
| msbuild/Xamarin.Shared/Xamarin.Shared.targets | Ensures framework post-processing items get Kind=Framework metadata to drive correct strip behavior. |
| msbuild/Xamarin.MacDev.Tasks/Tasks/SymbolStrip.cs | Adds a path-based fallback to treat framework binaries as “framework” even when Kind metadata is missing. |
✅ API diff for current PR / commitNET (empty diffs)✅ API diff vs stableNET (empty diffs)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
🚀 [CI Build #b9e83dd] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 199 tests passed 🎉 Tests counts✅ assembly-processing: All 1 tests passed. Html Report (VSDrops) Download macOS tests✅ Tests on macOS Monterey (12): All 5 tests passed. [attempt 2] Html Report (VSDrops) Download Linux Build VerificationPipeline on Agent |
A Release build of an app that references a binding project with an embedded dynamic framework failed with:
The SymbolStrip task only passes '-S -x' to strip (to strip just debug/local symbols) when an item's 'Kind' metadata is 'Framework'/'Dynamic' (or the path ends in '.dylib'); otherwise it does a full strip, which fails for a dynamic library that references undefined symbols (objc_msgSend, ...) via the indirect symbol table.
This regressed in commit 6b9cfc9 ("[msbuild] Filter static frameworks from post-processing items. Fixes #24840.", #24845), which changed the framework post-processing item in Xamarin.Shared.targets from:
to:
@(_ResolvedNativeReference)carried theKind=Frameworkmetadata (as the removed condition shows), but@(_FilteredFrameworkToPublish)does not, so the metadata was silently lost. Frameworks embedded in a binding project are extracted by the linker without 'Kind' metadata, so they reached the SymbolStrip task with an empty 'Kind' and got a full strip. Apps that use a direct<NativeReference Kind="Framework">are not affected (the Kind flows through); only binding-embedded frameworks are.Fix this in two places:
Set
Kind=Frameworkon the framework _PostProcessingItem (the block only ever contains frameworks), restoring the metadata the SymbolStrip task relies on.Also detect frameworks by path in the SymbolStrip task (an item inside a '.framework' directory), mirroring the existing '.dylib' fallback, so a full strip is never done on a framework even if the 'Kind' metadata is missing.
Also add a test (StripEmbeddedDynamicFramework) that builds an app which references a binding project that embeds a dynamic framework (NoBindingEmbedding=false) with symbol stripping enabled, and asserts the build succeeds. Without the fix this fails at the strip step. The test builds in Release (so the linker extracts the framework into the post-processing path), with a single RuntimeIdentifier (frameworks aren't post-processed in multi-RID builds) and NoSymbolStrip=false (so the framework is stripped even for the simulator).
The existing binding projects that embed a framework only embed static libraries (as frameworks), which are filtered out and never copied to the app (so never stripped). The one project that embeds a dynamic framework (EmbeddedFrameworkInBindingProjectApp, which embeds XTest.framework) didn't hit the problem, because XTest.framework (built from libframework.m) doesn't call any external functions and so can be fully stripped. Make libframework.m send an Objective-C message so the framework binary imports an Objective-C runtime function referenced via the indirect symbol table; such a binary can't be fully stripped, so the test now exercises the strip code path.
Fixes #25952
🤖 Pull request created by Copilot