Skip to content

3.3.0 - Matching dSYMs ride in the xcframeworks

Choose a tag to compare

View all tags
@superuser404notfound superuser404notfound released this 12 Sep 19:43
· 15 commits to main since this release
3.3.0
4e58942

Same n8.1.2 FFmpeg, the same dav1d, zimg and libzvbi, the same configure flags and the same decoder set as 3.2.1. What changed is what the release carries: every slice a shipped app can embed now brings its own dSYM, so a crash inside FFmpeg symbolicates.

What it fixes

An App Store Connect upload of an app that embeds these frameworks answered with, once per framework:

The archive did not include a dSYM for the Libavcodec.framework with the UUIDs [DD90B4B5-298C-335B-8C61-46A0A900D74D].

The libraries were compiled --disable-debug and installed --enable-stripping, so the debug information never existed and no dSYM could be produced from them. Every frame of a crash inside FFmpeg stayed an address. Reported as #4.

What ships now

  • All four builds (FFmpeg, dav1d, zimg, libzvbi) compile with -gline-tables-only: function names, file and line, and inlined frames, which is what a crash report resolves against, without the type information that makes up the bulk of full -g DWARF. Generated code is unchanged, and so is the optimization level. zimg had been taking autoconf's default -g -O2 all along; both halves are now set explicitly rather than inherited.
  • FFmpeg's install-time stripping is off, so the linker's debug map survives into build/thin where dsymutil reads it. build.sh lipos the per-architecture DWARF into one dSYM per framework and strips the shipped binary exactly as before. lipo, install_name_tool, strip -x and codesign all leave LC_UUID alone, which is what keeps the pair valid.
  • xcodebuild -create-xcframework -debug-symbols puts the dSYM into the slice. Xcode copies it into .xcarchive/dSYMs when it embeds the framework, so adopters do nothing at all.

Verified

A throwaway tvOS app embedding AetherLibavcodec.xcframework, archived with plain xcodebuild archive:

DsymProbe.xcarchive/dSYMs/
  AetherLibavcodec.framework.dSYM
  DsymProbe.app.dSYM

The archived framework binary and the archived dSYM carry the same UUID, and dwarfdump --lookup on the dSYM resolves an address to avcodec_open2 in avcodec.c:145.

DebugSymbolsTests pins both halves against the shipped xcframeworks: every non-simulator slice has a DebugSymbolsPath whose dSYM exists, and the dSYM's UUIDs match the binary's, architecture by architecture. Against 3.2.1's binaries the suite records 37 issues, which is what it is for.

Simulator slices ship without dSYMs

Deliberate: a simulator slice reaches neither an App Store archive nor a user's crash report, and its symbols would put another 45 MB of binaries into every clone of this package. ./build.sh writes them to build/dsyms for local use, and the test suite pins their absence so it stays a decision.

Releases before 3.3.0

They have no dSYMs and none can be made for them. The debug information was never compiled in, and a rebuild produces different UUIDs, which symbolicate nothing for binaries already distributed. Symbols and binaries are a pair per build.

Assets 2
Loading