DYDL error for iOS app on mac running on Big Sur archived with Xcode 13.3 RC

When I archive my iOS app with Xcode 13.3 RC and run it on macOS Big Sur, the app crashes on launch with a DYDL error:

Termination Reason:    DYLD, [0x1] Library missing

Dyld Error Message:
  dyld: Using shared cache: 331F452F-2BAE-3A64-AD52-0029F44B1379
dependent dylib '@rpath/SomeFramework.framework/SomeFramework' not found for '/private/var/folders/*/SomeApp.app/SomeApp'. chained fixups, seg_count exceeds number of segments

The app runs fine on macOS Monterey and on iOS 13, 14, 15. The LD_RUNPATH_SEARCH_PATH in the build settings is correct and when inspecting the binary with otool -l the LC_RPATH entries are also correct.

When archiving the app with Xcode 13.2.1, it runs fine on macOS Big Sur.

Has anybody experienced the same and knows a workaround?

I've filed a feedback: FB9951126

Answered by _tom_ in 710256022

the issues where resolved with Xcode 13.3.1

Think I'm running into a similar issue with an iOS app with an iOS 14 minimum target built with Xcode 13.3. App runs fine on iOS15, crashes with a similar error on iOS 14

Same thing is happening to us (with iOS 14), did you find a solution?

Having the same problem. My app will launch "tethered" from Xcode on iOS 14 but will not launch from SpringBoard. Also inspected binary with otool, everything looks good. This appears to be due to the following change from the Xcode 13.3 release notes: "The new chained fixups format is the default linking method when targeting macOS 11 or later, iOS 13.4 or later, watchOS 7.0 or later, and tvOS 14.0 or later. This new format results in smaller LINKEDIT segments in binaries. When targeting earlier operating system releases, the linker continues to generate the traditional opcode format in LINKEDIT for fixups, rebases, and binds. (85572905)". I wonder if there is a way to disable this new chained fixups format as a temporary fix.

xcrun dyld_info -fixup_chains /path/to/Framework.framework/Framework also reports this issue "chained fixups, seg_count exceeds number of segments" so it seems like something is corrupted in the dynamic linking information of the binary.

Following a hunch that I got from reading info on this related issue https://forums.swift.org/t/async-await-crash-on-ios14-with-xcode-13-2-1/54541/48, I disabled the "enable bitcode" build setting for my framework (it was already disabled for my app, so this isn't a problem - unfortunately bitcode really should be enabled, but this might be a temporary fix while we wait for an official one). I hypothesize that disabling bitcode altogether makes Xcode not put any bitcode segment in the binary, which fixes the seg_count issue (the cause of which, according to the swift.org link is that Xcode stripped the bitcode segment but didn't update the seg_count properly).

You can temporarily mitigate this issue (or at least I could) by disabling the new chained fixups link method that was enabled per this change in the Xcode 13.3 release notes:

The new chained fixups format is the default linking method when targeting macOS 11 or later, iOS 13.4 or later, watchOS 7.0 or later, and tvOS 14.0 or later. This new format results in smaller LINKEDIT segments in binaries. When targeting earlier operating system releases, the linker continues to generate the traditional opcode format in LINKEDIT for fixups, rebases, and binds. (85572905)

To disable the chained fixups, go to the "Other Linker Flags" build setting in Xcode and add two in the following order: -Xlinker -no_fixup_chains. (It's surprising to me that you need -Xlinker here but I got errors without it).

This should be viewed as a temporary workaround, because the chained fixups is a legitimate improvement to binary size and build time. Ideally Apple will correct this so that we can leverage that improvement on older versions of iOS like they seem to have intended.

The issue is that SomeFramework.framework was built with embedded bitcode (which is stored in a special segment), then the bit-code was removed. A bug in the bitcode removal tool is leaving the segment counts askew. The work around is to change the build settings such that "Enable Bitcode = No" for SomeFramework.framework (or more generally, disable bitcode everywhere in the app).

👋 Hi! My team hit the same issue with a build using Xcode 13.3. It only impact some users so it was very tough to figure out what was going on. Thanks to this answer, we were able to solve the issue by disabling Bitcode. Is this bug in the bitcode removal tool something we'll need to wait until the next version of Xcode to be fix, or is this something Apple will fix on their side? Is there any way that we will know when we can enable Bitcode again? Thanks!

Accepted Answer

the issues where resolved with Xcode 13.3.1

DYDL error for iOS app on mac running on Big Sur archived with Xcode 13.3 RC
 
 
Q