Include matching dSYMs with dynamic XCFramework releases

[cocoHMC]

App Store Connect accepts an archive using FFmpegBuild 2.5.0, but reports missing matching dSYMs for the bundled dynamic frameworks. This prevents complete symbolication of crashes inside those libraries.

The 2.5.0 build.sh configures FFmpeg with --enable-stripping --disable-debug and strips the packaged frameworks. The published tree and release do not appear to include corresponding dSYMs.

Could future binary releases preserve debug information during compilation, run dsymutil before stripping, and include matching per-platform dSYMs when creating the XCFrameworks (or publish a separate matching symbols archive)? If the exact 2.5.0 symbols already exist, please point consumers to them; rebuilding creates different UUIDs and cannot repair symbolication for existing distributed binaries.

Observed on the tvOS arm64 slices with Xcode 27 RC 27A266a. Affected frameworks: Libavcodec, Libavfilter, Libavformat, Libavutil, Libdav1d, Libswresample, Libswscale, Libzimg and Libzvbi. The application and extension's own dSYMs are present, and the App Store upload succeeds. This report concerns dependency crash diagnostics, not an upload rejection.

Example warning:

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

Relevant build settings: https://github.com/superuser404notfound/FFmpegBuild/blob/2.5.0/build.sh

[superuser404notfound]

Shipped in 3.3.0, and it needs no step on the adopter side: every slice a shipped app can embed (iOS, tvOS and visionOS device, macOS) now carries its dSYM inside the xcframework, and Xcode copies it into .xcarchive/dSYMs when it embeds the framework. If the stack arrives through AetherEngine, it is in 6.84.0.

What the build does 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, and none of the type information that makes up the bulk of full -g DWARF. Generated code and the optimization level are unchanged.
• --enable-stripping is gone, because make install took the linker's debug map with it before anything could read it. dsymutil now runs over each thin library, the per-architecture DWARF is lipo'd into one dSYM per framework, and the shipped binary is stripped exactly as before. lipo, install_name_tool, strip -x and codesign all leave LC_UUID alone, which is what keeps the binary and its dSYM a pair.
• xcodebuild -create-xcframework -debug-symbols puts the dSYM into the slice.

Verified rather than assumed, on a throwaway tvOS app that embeds AetherLibavcodec.xcframework and is 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 resolves an address in it to avcodec_open2 in avcodec.c:145. A test in the suite pins both halves against the shipped xcframeworks from here on: every non-simulator slice has a dSYM, and its UUIDs are the binary's, architecture by architecture.

Two points worth being explicit about:

• Simulator slices ship without dSYMs deliberately. They reach neither an archive nor a user's crash report, and they would add another 45 MB of binaries to every checkout of the package. ./build.sh writes them to build/dsyms for local use.
• The 2.5.0 symbols do not exist, and cannot be made. That build was configured --disable-debug, so no DWARF was ever produced, and a rebuild carries different UUIDs, as noted in the report. There is nothing to point at for binaries that already shipped. One more thing worth knowing when moving up: 3.0.0 renamed the frameworks to AetherLibavcodec and friends so this build can sit in an app that already has an FFmpeg, so the Libavcodec.framework in that warning is the pre-3.0.0 name.

Thanks for the report. The UUID line and the link to the exact build.sh made this a short investigation. A note on whether the warnings are gone on the next upload would be welcome.