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

Up vote post of _tom_ Down vote post of _tom_
3.9k views
Posted by
_tom_
Reply

  • 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

    —
    tdolik01

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

    —
    florent alexandre

  • 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.

    —
    nrfa

Accepted Reply

the issues where resolved with Xcode 13.3.1

Posted by
_tom_
Up vote reply of _tom_ Down vote reply of _tom_
Post marked as solved

  • I was having the same issue, this solved it. Thanks!!!

    —
    santiagomartin
Add a Comment

Replies

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.

Posted by
nrfa
Post not yet marked as solved Up vote reply of nrfa Down vote reply of nrfa
Add a Comment

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).

Posted by
Developer Tools Engineer
Post not yet marked as solved Up vote reply of Developer Tools Engineer Down vote reply of Developer Tools Engineer

  • Hi, we're also struggling with this and the framework in question is a Swift package. Is there a way to specifically disable bitcode for packages or should it be enough to disable it in the Xcode project that builds the app (which contains the package in question)? I did set "Enable Bitcode = No" in the Xcode project, but this did not fix the error.

    —
    Aurelian

  • yes, I my case I needed

    linkerSettings: [ .unsafeFlags(["-Xlinker", "-no_fixup_chains"]) ]

    on every swiftPM dynamic library product! BitCode is disabled with ENABLE_BITCODE = NO on all none swiftPM targets. So this is an issue maybe with swiftPM, bitcode and the new format for the linker/DYDL loader.

    —
    simonpierreroy
Add a Comment

👋 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!

Posted by
brian.boyle@intercom.io
Up vote reply of brian.boyle@intercom.io Down vote reply of brian.boyle@intercom.io
Add a Comment

the issues where resolved with Xcode 13.3.1

Posted by
_tom_
Up vote reply of _tom_ Down vote reply of _tom_
Post marked as solved

  • I was having the same issue, this solved it. Thanks!!!

    —
    santiagomartin
Add a Comment