Apple’s library technology has a long and glorious history, dating all the way back to the origins of Unix. This does, however, mean that it can be a bit confusing to newcomers. This is my attempt to clarify some terminology. If you have any questions or comments about this, start a new thread and tag it with Linker so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" An Apple Library Primer Apple’s tools support two related concepts: Platform — This is the platform itself; macOS, iOS, iOS Simulator, and Mac Catalyst are all platforms. Architecture — This is a specific CPU architecture used by a platform. arm64 and x86_64 are both architectures. A given architecture might be used by multiple platforms. The most obvious example of this arm64, which is used by all of the platforms listed above. Code built for one platform will not work on another platform, even if both platforms use the same architecture. Code is usually packaged in either a Mach-O file or a static library. Mach-O is used for executables, dynamic libraries, bundles, and object files. These can have a variety of different extensions; the only constant is that .o is always used for a Mach-O containing an object file. Use otool and nm to examine a Mach-O file. Use vtool to quickly determine the platform for which it was built. Use size to get a summary of its size. Use dyld_info to get more details about a dynamic library. IMPORTANT All the tools mentioned here are documented in man pages; for information on how to access that documentation, see Reading UNIX Manual Pages. The term Mach-O image refers to a Mach-O that can be loaded and executed without further processing. That includes executables, dynamic libraries, and bundles, but not object files. A dynamic library has the extension .dylib. You may also see this called a shared library. A framework is a bundle structure with the .framework extension that has both compile-time and run-time roles: At compile time, the framework combines the library’s headers and its stub library (stub libraries are explained below). At run time, the framework combines the library’s code, as a Mach-O dynamic library, and its associated resources. The exact structure of a framework varies by platform. For the details, see Placing Content in a Bundle. macOS supports both frameworks and standalone dynamic libraries. Other Apple platforms support frameworks but not standalone dynamic libraries. Historically these two roles were combined, that is, the framework included the headers, the dynamic library, and its resources. These days Apple ships different frameworks for each role. That is, the macOS SDK includes the compile-time framework and macOS itself includes the run-time one. Most third-party frameworks continue to combine these roles. A static library is an archive of one or more object files. It has the extension .a. Use ar, libtool, and ranlib to inspect and manipulate these archives. The static linker, or just the linker, runs at build time. It combines various inputs into a single output. Typically these inputs are object files, static libraries, dynamic libraries, and various configuration items. The output is most commonly a Mach-O image, although it’s also possible to output an object file. The linker may also output metadata, such as a link map (see Using a Link Map to Track Down a Symbol’s Origin). The linker has seen three major implementations: ld — This dates from the dawn of Mac OS X. ld64 — This was a rewrite started in the 2005 timeframe. Eventually it replaced ld completely. If you type ld, you get ld64. ld_prime — This was introduced with Xcode 15. This isn’t a separate tool. Rather, ld now supports the -ld_classic and -ld_new options to select a specific implementation. Note During the Xcode 15 beta cycle these options were -ld64 and -ld_prime. I continue to use those names because the definition of new changes over time (some of us still think of ld64 as the new linker ;–). The dynamic linker loads Mach-O images at runtime. Its path is /usr/lib/dyld, so it’s often referred to as dyld, dyld, or DYLD. Personally I pronounced that dee-lid, but some folks say di-lid and others say dee-why-el-dee. IMPORTANT Third-party executables must use the standard dynamic linker. Other Unix-y platforms support the notion of a statically linked executable, one that makes system calls directly. This is not supported on Apple platforms. Apple platforms provide binary compatibility via system dynamic libraries and frameworks, not at the system call level. Note Apple platforms have vestigial support for custom dynamic linkers (your executable tells the system which dynamic linker to use via the LC_LOAD_DYLINKER load command). This facility originated on macOS’s ancestor platform and has never been a supported option on any Apple platform. The dynamic linker has seen 4 major revisions. See WWDC 2017 Session 413 (referenced below) for a discussion of versions 1 through 3. Version 4 is basically a merging of versions 2 and 3. The dyld man page is chock-full of useful info, including a discussion of how it finds images at runtime. One of the most common points of confusion with dynamic linker is the way that the dynamic linker identifies dynamic libraries. There are two standard approaches to this, as described in Dynamic Library Identification. Xcode 15 introduced the concept of a mergeable library. This a dynamic library with extra metadata that allows the linker to embed it into the output Mach-O image, much like a static library. Mergeable libraries have many benefits. For all the backstory, see WWDC 2023 Session 10268 Meet mergeable libraries. For instructions on how to set this up, see Configuring your project to use mergeable libraries. If you put a mergeable library into a framework structure you get a mergeable framework. Xcode 15 also introduced the concept of a static framework. This is a framework structure where the framework’s dynamic library is replaced by a static library. Note It’s not clear to me whether this offers any benefit over creating a mergeable framework. Earlier versions of Xcode did not have proper static framework support. That didn’t stop folks trying to use them, which caused all sorts of weird build problems. A universal binary is a file that contains multiple architectures for the same platform. Universal binaries always use the universal binary format. Use the file command to learn what architectures are within a universal binary. Use the lipo command to manipulate universal binaries. A universal binary’s architectures are either all in Mach-O format or all in the static library archive format. The latter is called a universal static library. A universal binary has the same extension as its non-universal equivalent. That means a .a file might be a static library or a universal static library. Most tools work on a single architecture within a universal binary. They default to the architecture of the current machine. To override this, pass the architecture in using a command-line option, typically -arch or --arch. An XCFramework is a single document package that includes libraries for any combination of platforms and architectures. It has the extension .xcframework. An XCFramework holds either a framework, a dynamic library, or a static library. All the elements must be the same type. Use xcodebuild to create an XCFramework. For specific instructions, see Xcode Help > Distribute binary frameworks > Create an XCFramework. Historically there was no need to code sign libraries in SDKs. If you shipped an SDK to another developer, they were responsible for re-signing all the code as part of their distribution process. Xcode 15 changes this. You should sign your SDK so that a developer using it can verify this dependency. For more details, see WWDC 2023 Session 10061 Verify app dependencies with digital signatures and Verifying the origin of your XCFrameworks. A stub library is a compact description of the contents of a dynamic library. It has the extension .tbd, which stands for text-based description (TBD). Apple’s SDKs include stub libraries to minimise their size; for the backstory, read this post. Stub libraries currently use YAML format, a fact that’s relevant when you try to interpret linker errors. Use the tapi tool to create and manipulate these files. In this context TAPI stands for a text-based API, an alternative name for TBD. Oh, and on the subject of tapi, I’d be remiss if I didn’t mention tapi-analyze! Mach-O uses a two-level namespace. When a Mach-O image imports a symbol, it references the symbol name and the library where it expects to find that symbol. This improves both performance and reliability but it precludes certain techniques that might work on other platforms. For example, you can’t define a function called printf and expect it to ‘see’ calls from other dynamic libraries because those libraries import the version of printf from libSystem. To help folks who rely on techniques like this, macOS supports a flat namespace compatibility mode. This has numerous sharp edges — for an example, see the posts on this thread — and it’s best to avoid it where you can. If you’re enabling the flat namespace as part of a developer tool, search the ’net for dyld interpose to learn about an alternative technique. WARNING Dynamic linker interposing is not documented as API. While it’s a useful technique for developer tools, do not use it in products you ship to end users. Apple platforms use DWARF. When you compile a file, the compiler puts the debug info into the resulting object file. When you link a set of object files into a executable, dynamic library, or bundle for distribution, the linker does not include this debug info. Rather, debug info is stored in a separate debug symbols document package. This has the extension .dSYM and is created using dsymutil. Use symbols to learn about the symbols in a file. Use dwarfdump to get detailed information about DWARF debug info. Use atos to map an address to its corresponding symbol name. Different languages use different name mangling schemes: C, and all later languages, add a leading underscore (_) to distinguish their symbols from assembly language symbols. C++ uses a complex name mangling scheme. Use the c++filt tool to undo this mangling. Likewise, for Swift. Use swift demangle to undo this mangling. Over the years there have been some really good talks about linking and libraries at WWDC, including: WWDC 2023 Session 10268 Meet mergeable libraries WWDC 2022 Session 110362 Link fast: Improve build and launch times WWDC 2022 Session 110370 Debug Swift debugging with LLDB WWDC 2021 Session 10211 Symbolication: Beyond the basics WWDC 2019 Session 416 Binary Frameworks in Swift — Despite the name, this covers XCFrameworks in depth. WWDC 2018 Session 415 Behind the Scenes of the Xcode Build Process WWDC 2017 Session 413 App Startup Time: Past, Present, and Future WWDC 2016 Session 406 Optimizing App Startup Time Note The older talks are no longer available from Apple, but you may be able to find transcripts out there on the ’net. Historically Apple published a document, Mac OS X ABI Mach-O File Format Reference, or some variant thereof, that acted as the definitive reference to the Mach-O file format. This document is no longer available from Apple. If you’re doing serious work with Mach-O, I recommend that you find an old copy. It’s definitely out of date, but there’s no better place to get a high-level introduction to the concepts. The Mach-O Wikipedia page has a link to an archived version of the document. For the most up-to-date information about Mach-O, see the declarations and doc comments in <mach-o/loader.h>. Revision History 2024-05-08 Added links to the demangling tools. 2024-04-30 Clarified the requirement to use the standard dynamic linker. 2024-03-02 Updated the discussion of static frameworks to account for Xcode 15 changes. Removed the link to WWDC 2018 Session 415 because it no longer works )-: 2024-03-01 Added the WWDC 2023 session to the list of sessions to make it easier to find. Added a reference to Using a Link Map to Track Down a Symbol’s Origin. Made other minor editorial changes. 2023-09-20 Added a link to Dynamic Library Identification. Updated the names for the static linker implementations (-ld_prime is no more!). Removed the beta epithet from Xcode 15. 2023-06-13 Defined the term Mach-O image. Added sections for both the static and dynamic linkers. Described the two big new features in Xcode 15: mergeable libraries and dependency verification. 2023-06-01 Add a reference to tapi-analyze. 2023-05-29 Added a discussion of the two-level namespace. 2023-04-27 Added a mention of the size tool. 2023-01-23 Explained the compile-time and run-time roles of a framework. Made other minor editorial changes. 2022-11-17 Added an explanation of TAPI. 2022-10-12 Added links to Mach-O documentation. 2022-09-29 Added info about .dSYM files. Added a few more links to WWDC sessions. 2022-09-21 First posted.

I often find myself helping folks with dynamic library problems. These problems manifest in many different ways, but they all have one common factor: The dynamic library has an atypical install name. Sometimes this was inherited from macOS’s deep past, but most often it’s because folks aren’t aware of the two well-trodden paths through this particular minefield. This post is my attempt to rectify that. If you have questions or comments about this, start a new thread here on DevForums. Tag it with Linker so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Dynamic Library Identification Apple’s dynamic linker has a lot of flexibility. Much of this flexibility exists for historical reasons, and it’s better for modern programs to follow one of two well-trodden paths: Most dynamic libraries should use an rpath-relative install name, as explained in Dynamic Library Standard Setup for Apps. In some cases it might make sense to use a full path for your install name, per Dynamic Library Full Path Alternative. To understand these options, you need to know a little bit about how the dynamic linker works, which is the subject of this post. Note This post covers some of the same ground as Embedding nonstandard code structures in a bundle, but in a less official way (-: Install Name Every dynamic library has an install name. This name identifies the library to the dynamic linker. When you link to a dynamic library, the static linker records the library’s install name in your Mach-O image. When the dynamic linker loads your Mach-O image, it uses those recorded install names to find and load the libraries you depend on. Note There are many different aliases for the term install name, including id, identification name, or install path. To see a library’s install name, run otool and examine the LC_ID_DYLIB load command: % otool -l libWaffle.dylib | grep -A 2 LC_ID_DYLIB cmd LC_ID_DYLIB cmdsize 48 name @rpath/libWaffle.dylib … Note The Mach-O load commands and their associated structures are defined in <mach-o/loader.h>. For example LC_ID_DYLIB is associated with the dylib_command structure. To see the install names of the libraries imported by a Mach-O image, run otool and examine the LC_LOAD_DYLIB load commands: % otool -l libVarnish.dylib | grep -A 2 LC_LOAD_DYLIB cmd LC_LOAD_DYLIB cmdsize 48 name @rpath/libWaffle.dylib … -- cmd LC_LOAD_DYLIB cmdsize 56 name /usr/lib/libSystem.B.dylib … Alternatively, use the -L option: % otool -L libVarnish.dylib … @rpath/libVarnish.dylib … @rpath/libWaffle.dylib … /usr/lib/libSystem.B.dylib … This displays the library’s own install name first, followed by the install names of all the libraries it imports. If you’re building a dynamic library with Xcode, use the Dynamic Library Install Name build setting to set the install name. If you’re building from the command line, pass the -install_name option to ld. For more about this, see the ld man page. It’s best to set the install name at build time and not change it. However, if you’re working with an existing dynamic library that has the wrong install name, you can usually change it using install_name_tool. See the install_name_tool man page for details. Runtime Path List Way back in the day, a dynamic library’s install name was the full path of the installed library. That’s why it’s called the install name. However, full paths don’t work in some situations. For example, if you have a library embedded within an app, you can’t use an full path because the app might not be installed in the Applications folder. To address this problem Apple updated the dynamic linker to support a number of special install name prefixes. At runtime it replaces the prefix with an appropriate path. For example, @executable_path is replaced with the path to the directory containing the processes main executable. For a full list of these prefixes see the dyld man page. However, if you’re creating a dynamic library you’ll want to focus on the runtime path, @rpath, or just rpath for short. The exact details of how this works are complex, see the man page for the full story, but the basic gist is that: The dynamic linker maintains a list of rpath directories. When it loads a Mach-O image, the dynamic linker looks for LC_RPATH load commands in the image. For each one it finds, it adds a new directory to the rpath list. When a Mach-O image imports a library with an rpath-relative install name, the dynamic linker searches for that library in each directory in the list. This may sound a bit abstract, so you might want to hop on over to Dynamic Library Standard Setup for Apps for some examples of how this works in practice. If you’re building a Mach-O image with Xcode, use the Runpath Search Paths build setting to add rpath directories. If you’re building from the command line, pass the -rpath option to ld. For more about this, see the ld man page. It’s best to configure your rpath directories at build time. However, if you’re working with an existing Mach-O that has the wrong rpath directories, you can add, delete, and change them using install_name_tool. See the install_name_tool man page for details.

I am getting an following error while compiling the Fortran file with "gfortran TEST_1_fortran_only_fixed.f" ld: unsupported tapi file type '!tapi-tbd' in YAML file '/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/lib/libSystem.tbd' for architecture x86_64 collect2: error: ld returned 1 exit status Please help me to solve this issue

I have an application made from Flutter, which is possible to run on VisionOS by running as design to Ipad, and I would like that inside this application would be possible to go to mixed reality somehow. I am trying to do so far was to embedded the vision project that I have inside the swift application that flutter generates, but in this attempt I got an error from Xcode telling me that this way is not possible. I wonder if is there an another way that I could achieve my goal?

We use XCode 15.2 to build our application, but we found that the app crashes on iOS 12.1.1, while it works without crashing on iOS 12.5.7. We discovered that the crash is related to ImageLoaderMachO::doModInitFunctions. We're not sure what is causing this.

Hi everyone, I recently developed a Chess engine in C using Xcode on my old Mac. After purchasing a new Mac, I attempted to run my project but encountered the following error: dyld[12498]: dyld cache '(null)' not loaded: syscall to map cache into shared region failed dyld[12498]: Library not loaded: /usr/lib/libSystem.B.dylib Referenced from: &lt;7D3E4140-BCEC-3C04-8C77-11EB7AEEB393&gt; /Users/simonmizrahi/Library/Developer/Xcode/DerivedData/Chesspresso_Take_2-awdtkeshpaucukgespypcbgxgsvy/Build/Products/Debug/Chesspresso Take 2 Reason: tried: '/Users/simonmizrahi/Library/Developer/Xcode/DerivedData/Chesspresso_Take_2-awdtkeshpaucukgespypcbgxgsvy/Build/Products/Debug/libSystem.B.dylib' (no such file), '/usr/lib/system/introspection/libSystem.B.dylib' (no such file, no dyld cache), '/usr/lib/libSystem.B.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/lib/libSystem.B.dylib' (no such file), '/usr/lib/libSystem.B.dylib' (no such file, no dyld cache)' I’ve reinstalled macOS and Xcode, but the issue persists. I’ve verified that libSystem.B.dylib is missing from /usr/lib/. I am quite anxious to find a solution, as I’ve read similar posts but do not understand how to fix the problem in my specific case. Could anyone provide guidance on how to resolve this and get my project running on my new Mac? Thanks in advance for your help!

When I Run Php Artisan Command in PhpStorm Laravel Project The below results show in the terminal. dyld[11387]: Library not loaded: @loader_path/../../../../opt/icu4c/lib/libicuio.73.dylib Referenced from: &lt;27B43AEF-470B-32CD-9521-AA834300394F&gt; /usr/local/Cellar/php/8.2.10/bin/php Reason: tried: '/usr/local/Cellar/php/8.2.10/bin/../../../../opt/icu4c/lib/libicuio.73.dylib' (no such file), '/usr/local/lib/libicuio.73.dylib' (no such file), '/usr/lib/libicuio.73.dylib' (no such file, not in dyld cache) zsh: abort php artisan

Hi, I am writing my own little toy programming language and when I try to link the binary object file (.o file) it requires a _main symbol. I wonder if there is a way to exclude this, presumably, a C runtime requirement? Is it safe to provide a stub _main symbol, or provide a the _main as the entry point to my own little runtime? What is the correct way to invoke the linker with the appropriate flags?

Xcode will build and analyze fine using the Debug build configuration but trying to use Analyze or Archive with Release configuration generates 3 errors: Undefined symbol: protocol conformance descriptor, Undefined symbol: type metadata accessor, and Undefined symbol: nominal type descriptor causing the linker to command to fail. The library is included and already linked and a previous version did not have the error so I think it's a code issue but not quite sure what it is or how to fix! The project/package can be found here: https://github.com/kudit/Device/tree/v2.1.17 (to reproduce, checkout this version and rename appending ".swiftpm" to the folder, then right-click to show package contents, open the Development folder and open the Xcode project there. It's done this way so the package can be imported and edited on iPad Swift Playgrounds)

Hi there, I have just recently had a go at trying to build an app using unreal engine. After much difficulty of finally getting the app to sign, build and deploy I am having issues with the app crashing immediately after opening it. I have had a look at the crash log to find it including EXC_BAD_ACCESS (SIGSEGV) which I've come to understand means it may be accessing a value that doesn't exist. I was unable to understand or figure out any of the rest of it to find any clues on how to solve my issue. If anyone could point me in the right direction as to why the app is crashing, it would be greatly appreciated. crash log

I maintain a library that has thus far used Cocoapods to manage dependencies and also distribute an xcframework of the library. I'd now like to also distribute the same library through Swift Packages but am running into issues. I'm using the same xcframework in a local Swift Package and have added all the necessary dependencies to Package.swift, but when I attempt to add this Swift Package to a test app, the app will build correctly but fail at runtime due to a missing .framework file for a dependency I'll just call THE_DEPENDENCY: dyld[61483]: Library not loaded: @rpath/THE_DEPENDENCY.framework/THE_DEPENDENCY Referenced from: <75074516-C1CD-3251-8807-94A7502176A7> /Users/ME/Library/Developer/Xcode/DerivedData/MY_TEST_APP-bwfsfwjjnagdurdnjrhhdppgitvr/Build/Products/Debug-appletvsimulator/MY_LIBRARY.framework/MY_LIBRARY Reason: tried: '/Users/ME/Library/Developer/Xcode/DerivedData/MY_TEST_APP-bwfsfwjjnagdurdnjrhhdppgitvr/Build/Products/Debug-appletvsimulator/THE_DEPENDENCY.framework/THE_DEPENDENCY' (no such file) Indeed, there is no THE_DEPENDENCY.framework file anywhere, it is only present in a version of the test app that uses Cocoapods. As you can see, the reference to this file arises from MY_LIBRARY, and in MY_LIBRARY.xcodeproj I can see there is a reference to THE_DEPENDENCY.framework, which appears as a consequence of running pod install. Thus, it looks to me like the .framework file appears either as part of Cocoapods dependency injection, or perhaps as a consequence of how that dependency is distributed through Cocoapods. I'm forced to install pods during my build process because, as I understand it, all dependencies must be available during the archiving process to avoid compilation errors. If the dependencies must be available during archiving, but adding the dependencies via Cocoapods creates a reference to .framework files that will not be present in a Swift Package project, what is the best practice for distributing xcframework binaries to both Cocoapods and Swift Package Manager? It looks as though I'll have to build two different xcframeworks: one built with dependencies provided via pods, and the other via swift packages. Is this correct?

Hello, I have a problem with an iOS app that is deployed via the MDM system Intune. The app closes immediately after starting. The APP works without distribution via the MDM. Devices with iOS 17 also work. I am attaching a crash report. (txt is ips) Unfortunately I have no idea how to solve the problem because it only occurs via the MDM and therefore I cannot debug it. The problem occurs in production environment. Please help me with the solution. Insight Mobile-2024-06-24-144828.txt Best regards Moritz

dyld[766]: Library not loaded: @rpath/lib/libswiftCoreGraphics.dylib Referenced from: /private/var/containers/Bundle/Application/94ECCB38-EB17-4A37-8D38-5D50018D135C/Coloring Book.app/Coloring Book Reason: tried: '/usr/lib/system/introspection/libswiftCoreGraphics.dylib' (no such file, not in dyld cache), '/usr/lib/swift/lib/libswiftCoreGraphics.dylib' (no such file, not in dyld cache), '/private/preboot/Cryptexes/OS/usr/lib/swift/lib/libswiftCoreGraphics.dylib' (no such file), '/private/var/containers/Bundle/Application/94ECCB38-EB17-4A37-8D38-5D50018D135C/Coloring Book.app/Frameworks/lib/libswiftCoreGraphics.dylib' (no such file), '/private/var/containers/Bundle/Application/94ECCB38-EB17-4A37-8D38-5D50018D135C/Coloring Book.app/Frameworks/lib/libswiftCoreGraphics.dylib' (no such file), '/usr/lib/swift/lib/libswiftCoreGraphics.dylib' (no such file, not in dyld cache), '/private/preboot/Cryptexes/OS/usr/lib/swift/lib/libswiftCoreGraphics.dylib' (no such file), '/private/var/containers/Bundle/Application/94ECCB38-EB17-4A37-8D38-5D50018D135C/Coloring Book.app/Frameworks/lib/libswiftCoreGraphics.dylib' (no such file), '/private/var/containers/Bundle/Application/94ECCB38-EB17-4A37-8D38-5D50018D135C/Coloring Book.app/Frameworks/lib/libswiftCoreGraphics.dylib' (no such file)

I am using #canImport(JournalingSuggestions), but something is going wrong and my app is attempting to import the framework on iPad, and crashing on launch. How can I ensure that it's properly filtered out from everything except iPhone? import SwiftUI #if canImport(JournalingSuggestions) import JournalingSuggestions #endif struct JournalingSuggestionsView: View { var body: some View { #if canImport(JournalingSuggestions) JournalingSuggestionsPicker { Text("Open Journaling Suggestions") } onCompletion: { suggestion in print(suggestion) } #else Text("Journaling suggestions not available on this platform.") #endif } } Error: dyld[8689]: Library not loaded: /System/Library/Frameworks/JournalingSuggestions.framework/JournalingSuggestions Referenced from: <A656E6BC-4883-3245-BE71-3F84C2F41119> /private/var/containers/Bundle/Application/C6C11F57-AFAA-442A-B726-7AADDDB50D79/Catalog.app/Catalog Reason: tried: '/System/Library/Frameworks/JournalingSuggestions.framework/JournalingSuggestions' (no such file), '/private/preboot/Cryptexes/OS/System/Library/Frameworks/JournalingSuggestions.framework/JournalingSuggestions' (no such file), '/System/Library/Frameworks/JournalingSuggestions.framework/JournalingSuggestions' (no such file, not in dyld cache) System info: Xcode 15.2 iPadOS 17.3.1

I have an iOS app target with a framework dependency and want to merge that framework by setting MERGED_BINARY_TYPE to automatic in the app target's build settings. It all works fine until I add a (non-private) UIHostingController to the framework target. When I do this it crashes on startup with this message: dyld[15894]: Symbol not found: _OBJC_CLASS_$__TtC5Frame4MyVC. Xcode 15.1b3 Reported as bug via Feedback Assistant: FB13379276

Hi! I've been dealing with mergeable libraries quite some time. However I can't achieve the following scenario: I have 2 xcframeworks A and B that are merged as part of a third xcframework called C. And my app needs to import something from A and B. As per the documentation we have to remove the references from A and B from the final app and replace it with C. If I work on the same xcodepoj it works like a charm (maybe because of caches), but if I try to compile C as a separate XCFramework and distribute it as a packed library, the app is not able to resolve the symbols to A and B classes. This C xcframework is compiled with BUILD_LIBRARY_FOR_DISTRIBUTION se to true and if I check its swiftinterface files it is not declaring the symbols from A and B. However the size of the binary seems to have A and B. Is there any way to export A and B symbols as part of C's swiftinterface? If I add @_exported, it is forcing me to declare the import of A and B wherever I use them and therefore I'm going to have duplicated symbols Thanks!

I updated my project (a Swift-based Screen Saver) from Xcode 14 to 15, and while the project works fine, I'm seeing a bunch of warnings during the link phase like this: ld: warning: reexported library with install name '/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis' found at '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis.tbd' couldn't be matched with any parent library and will be linked directly Am I doing something wrong? Can I safely suppress these warnings?

I'm working on a macOS app. Due to security requirement, I add the following line in XCode other linker flags: -Wl,-sectcreate,__RESTRICT,__restrict,/dev/null But after testing, we found that app crashed at launch if system integrity protection disabled. Here is the report: System Integrity Protection: disabled Crashed Thread: 0 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace DYLD, Code 1 Library missing Library not loaded: @rpath/MyLib.framework/Versions/A/MyLib Referenced from: <845E83E4-9526-36F0-8A2D-ADD407697F4D> /Applications/MyApp/MyApp.app/Contents/MacOS/MyApp Reason: tried: '/System/Library/Frameworks/MyLib.framework/Versions/A/MyLib' (no such file, not in dyld cache), (security policy does not allow @ path expansion) (terminated at launch; ignore backtrace) Thread 0 Crashed: 0 dyld 0x185f3a55c __abort_with_payload + 8 1 dyld 0x185f46b10 abort_with_payload_wrapper_internal + 104 2 dyld 0x185f46b44 abort_with_payload + 16 3 dyld 0x185ecd584 dyld4::halt(char const*, dyld4::StructuredError const*) + 304 4 dyld 0x185eca254 dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3884 5 dyld 0x185ec8edc start + 1844 Looks like dyld can't load rpath if restrict segment exist & SIP disabled. Is there a way to fix it? The framework & dylib files needs to be in the bundle to avoid other app using them, so point to /usr/lib is not an option. Thanks.

Hi there, My app detects connected BlackMagic devices on a user's machine and this is done using the DeckLink SDK which first tries to load /Library/Frameworks/DeckLinkAPI.framework using CFBundleCreate. I have not been able to create a notarized app which successfully detects the devices. Either the DeckLinkAPI works or the app starts up without showing "the developer cannot be verified" on my test computer but never both. This is what I've tried so far: signed app: DeckLinkAPI available hardened runtime: DeckLinkAPI not available hardened runtime + com.apple.security.cs.disable-library-validation: DeckLinkAPI available, notarization succeeds yet the "the developer cannot be verified" I've also tried to use weak linking to DeckLinkAPI.framework instead of including the SDK's CFBundleCreate code but that made no difference: I still needed the com.apple.security.cs.disable-library-validation entitlement for that to work which caused "the developer cannot be verified". DeckLinkAPI.framework is notarized: > codesign --test-requirement="=notarized" --verify --verbose /Library/Frameworks/DeckLinkAPI.framework /Library/Frameworks/DeckLinkAPI.framework: valid on disk /Library/Frameworks/DeckLinkAPI.framework: satisfies its Designated Requirement /Library/Frameworks/DeckLinkAPI.framework: explicit requirement satisfied Is there any way to successfully notarize an app to use the DeckLink SDK or any other thirdparty notarized framework which is distributed seperately?

Looking for anyone that has some experience in getting Xcode to work with external compiler/linkers in what is tantamount to a foreign tool chain to build non-apple platform executables. For example, I want to ultimately use Xcode to edit, build, and push bare metal firmware (read "no operating system at external device"). Think of it as in how to use Xcode to develop the firmware in the processor in the ThunderBolt 4 cable (TPS65994AD) which runs a variant of the ARM Cortex-M machine code. Suppose I don't want to use TI's "Code Composer Studio (CCS)" but instead want to use Xcode which might drive some part of Code Composer Studio. Xcode supports external / foreign tool chains (or did) but the question is "have you done it successfully for any foreign platform?" and if so what was your approach? I'm trying to not waste a bunch of time with horrendous make file scripting only to find out that I did not have to do it or it headed down the wrong directions. I have a hard time believing that someone hasn't done this before for something even more monolithic like Arduino.

In Xcode 15 beta 6, building any Mac Catalyst project will encounter the following Linker warning. ld: warning: building for 'macCatalyst', but linking in dylib (/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa.tbd) built for 'macOS'

The following program demonstrates the issue. It prints: y = 2.000000 CGRectMake symbol not found What would cause the symbol not to be found when using the dlopen/dlsym functions? #import <CoreGraphics/CoreGraphics.h> #import <dlfcn.h> int main(int argc, const char * argv[]) { CGRect rect = CGRectMake(1.0, 2.0, 3.0, 4.0); printf("y = %f\n", rect.origin.y); void * handle = dlopen("/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics", RTLD_LAZY); if (handle == NULL) { printf("handle == NULL\n"); } else if (dlsym(handle, "CGRectMake") == NULL) { printf("CGRectMake symbol not found\n"); } return 0; } I am observing this issue with other symbols as well. What is special about them?