Use dyld to link in frameworks at runtime. Use ld to make your programs and link archive libraries at build time.

Posts under Linker tag

117 Posts
Sort by:

Post

Replies

Boosts

Views

Activity

An Apple Library Primer
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. Every dynamic library has an install name, which is how the dynamic linker identifies the library. Historically that was the path where you installed the library. That’s still true for most system libraries, but nowadays a third-party library should use an rpath-relative install name. For more about this, see Dynamic Library Identification. Mach-O images are position independent, that is, they can be loaded at any location within the process’s address space. Historically, Mach-O supported the concept of position-dependent images, ones that could only be loaded at a specific address. While it may still be possible to create such an image, it’s no longer a good life choice. Mach-O images have a default load address, also known as the base address. For modern position-independent images this is 0 for library images and 4 GiB for executables (leaving the bottom 32 bits of the process’s address space unmapped). When the dynamic linker loads an image, it chooses an address for the image and then rebases the image to that address. If you take that address and subtract the image’s load address, you get a value known as the slide. 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! Historically, the system maintained a dynamic linker shared cache, built at runtime from its working set of dynamic libraries. In macOS 11 and later this cache is included in the OS itself. Libraries in the cache are no longer present in their original locations on disk: % ls -lh /usr/lib/libSystem.B.dylib ls: /usr/lib/libSystem.B.dylib: No such file or directory Apple APIs, most notably dlopen, understand this and do the right thing if you supply the path of a library that moved into the cache. That’s true for some, but not all, command-line tools, for example: % dyld_info -exports /usr/lib/libSystem.B.dylib /usr/lib/libSystem.B.dylib [arm64e]: -exports: offset symbol … 0x5B827FE8 _mach_init_routine % nm /usr/lib/libSystem.B.dylib …/nm: error: /usr/lib/libSystem.B.dylib: No such file or directory 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 2025-02-17 Expanded the discussion of dynamic library identification. 2024-10-07 Added some basic information about the dynamic linker shared cache. 2024-07-26 Clarified the description of the expected load address for Mach-O images. 2024-07-23 Added a discussion of position-independent images and the image slide. 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.
0
0
8.3k
1w
Dynamic Library Identification
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.
0
0
3.6k
Sep ’23
Operator new/delete override only work for the first time for an iOS App on iOS16
Phenomenon We've found operator new/delete override in iOS app, only works for the first time when the app launches on iOS16, operator override is not working in the second and subsequent launch of the same app. Steps to reproduce Development environment: XCode 16.2 Create a new iOS Objective-C project in XCode In the project options page, choose the following settings: Name the project: OverrideNew Interface: Storyboard Language: Objective-C Testing System: None Add test code Change AppDelegate.m's file name to AppDelegate.mm to add the following C++ test code. Add the following code after #import "AppDelegate.h" #include &lt;os/log.h&gt; #include &lt;string&gt; static bool needLog = false; void* operator new(size_t size) { void* ptr = malloc(size); if(needLog) { // Log to prove override new works os_log_error(OS_LOG_DEFAULT, "Overrided new called. ptr: %p\n", ptr); } return ptr; } void operator delete(void* ptr) noexcept { free(ptr); if(needLog) { // Log to prove override delete works os_log_error(OS_LOG_DEFAULT, "Overrided delete called. ptr: %p\n", ptr); } } void StringConstructTest(void) { needLog = true; os_log_error(OS_LOG_DEFAULT, "Enter StringConstructTest1\n"); { std::string str; // a long string will trigger memory allocation on heap str = "Hello world and this is a long string.\n"; os_log_error(OS_LOG_DEFAULT, "%{public}s\n", str.c_str()); } os_log_error(OS_LOG_DEFAULT, "Exit StringConstructTest1\n"); needLog = false; } Call StringConstructTest() in didFinishLaunchingWithOptions method: - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // Override point for customization after application launch. StringConstructTest(); return YES; } Change build settings Change Minimum Deployments: iOS 16. Build and run the project on an iOS16 device, emulator can not reproduce the problem. Observe logs in Console app on Mac Use the following log filters: message type: error process: OverrideNew First launch First launch on device(not from a XCode debug launch), the log is: Enter StringConstructTest1 Overrided new called. ptr: 0x281f2f450 Hello world and this is a long string. Overrided delete called. ptr: 0x281f2f450 Exit StringConstructTest1 "Overrided new called" proved the override new operator is called. Second and subsequence launch Second and subsequence launch on device(not from a XCode debug launch), the log is: Enter StringConstructTest1 Hello world and this is a long string. Exit StringConstructTest1 No log for "Overrided new called", the subsequence launch, the override operator new is not called anymore. Expected behavior For every app launch, log "Overrided new called" will happen and operator override works. On iOS16, operator override only works for the first launch. I've also tested on iOS18, operator override works every time as expected. Question Is there a way to force operator override works every time on iOS16?
4
0
168
4d
dyld: Symbol not found ... certain MeshResource APIs on iOS 17.x
I submitted feedback as FB16463501 -- posting here for others to see, or maybe for Apple to share any help if there are workarounds, etc.: Targets below iOS 18.x fail to launch app due to dyld[xxxxx]: Symbol not found: errors when referencing: MeshResource.init(from:) async - https://developer.apple.com/documentation/realitykit/meshresource/init(from:)-b7hb i.e. dyld[61511]: Symbol not found: _$s10RealityKit12MeshResourceC0A10FoundationE4fromACSayAD0C10DescriptorVG_tYaKcfC MeshResource.replace(with:) async - https://developer.apple.com/documentation/realitykit/meshresource/replace(with:)-8uvri i.e. dyld[78830]: Symbol not found: _$s10RealityKit12MeshResourceC0A10FoundationE7replace4withyAcDE8ContentsV_tYaKF Targets tested that exhibit issue: (DYLD errors) Device: iOS 17.7.2, iPhone 14 Pro Max Simulator: iOS 17.5 (21F79), iPhone 15 System Information: macOS Version 15.3 (Build 24D60) Xcode 16.2 (23507) (Build 16C5032a) MRE -- include this code in your app: (no need to invoke, just reference) static func addOrUpdateEntityModel_MRE(_ entity: ModelEntity) async { let descriptor = MeshDescriptor(name: "MyDescriptor") do { if let modelComponent = entity.model { // update existing ModelComponent if let model = try? MeshResource.Model(id: "MyModelId", descriptors: [descriptor]) { var contents = MeshResource.Contents() contents.models = .init([model]) try await modelComponent.mesh.replace(with: contents) /// `dyld[78830]: Symbol not found: _$s10RealityKit12MeshResourceC0A10FoundationE7replace4withyAcDE8ContentsV_tYaKF` } } else { //create new ModelComponent /// Comment-out the 2 lines below == dyld error for above `MeshResource.replace(with:)` let meshRes = try await MeshResource(from: [descriptor]) /// `dyld[61511]: Symbol not found: _$s10RealityKit12MeshResourceC0A10FoundationE4fromACSayAD0C10DescriptorVG_tYaKcfC` entity.model = .init(mesh: meshRes, materials: [SimpleMaterial()]) } } catch { fatalError() } }
0
0
200
2w
Removing dependence on -undefined dynamic_lookup
One of the libraries that makes up my application depends on -undefined dynamic_lookup to link, and has since at least Snow Leopard if not earlier. I think iOS hasn't liked this for a while, but with the new linker I'm getting deprecation warnings even on OS X. I don't entirely understand what this flag does, other than it makes the build successful. :) So I'm at a loss on how to even approach fixing it. At this point, even links to useful resources would be appreciated, since googling hasn't yielded much beyond "remove -undefined to quiet the deprecation warning." FWIW, there is a bit of circular dependence between this library and another. On another OS, we need a carefully choreographed dance of building object files, then import libraries, then final linking to make this all work. So I suspect this may be related, but even if I'm correct, I don't know what would be the equivalent tools on Apple platforms.
1
0
186
2w
Issue Integrating C++ SDK
Hello Apple Team, I'm trying to import the Audodesk FBX SDK to my Objective-C iOS Project. The SDK is written in C++, but has support for iOS and the iOS simulator architectures. I've added the path to the include folder in the Header Search Path I've also added the paths to libfbxsdk.a in the Library Search Paths Finally, I've added the libfbxsdk.a file to the Link Binary with Libraries. However, when I build the project, I get the following error: building for 'iOS', but linking in object file (/Users/Lond/Documents/v2/Autodesk/iOS/2020.3.7/lib/ios/debug/libfbxsdk.a[28](fbxalloc.cxx.o)) built for 'macOS' In the terminal, if I type the command: 
lipo -info libfbxsdk.a I get the message Non-fat file: libfbxsdk.a is architecture: arm64 confirming that I'm using the library for the correct architecture.   Do I need to add any other confifuration option? (Like the other linker flag or something else) I'm quite new to C++, and integrating a C++ SDK into iOS is not easy.   I'm using Mac Os Sonoma 14.6.1 Tested on Xcode 15.4 and 16.2 Target Device: iPhone 13 Pro (iOS 17.6.1) iOS FBX SDK version: 2020.3.7 Link to the SDK if needed: https://aps.autodesk.com/developer/overview/fbx-sdk   Any help would be greatly appreciated Thank you
4
0
335
2w
Persistent "Framework 'Flutter' Not Found" Error When Building iOS Simulator
I'm currently facing a recurring issue while attempting to build my Flutter app for the iOS simulator. The build process fails with the following error Error (Xcode): Framework 'Flutter' not found Error (Xcode): Linker command failed with exit code 1 Steps I've Taken: Recreated the ios/ folder and cleared derived data: Used flutter clean to clean the project. Reinstalled CocoaPods with pod deintegrate followed by pod install. Verified Configuration: Checked AppDelegate and framework paths within Xcode. Set the deployment target to 14.0 in the Podfile. Additional Actions: Performed flutter clean again, followed by removal of Pods, .symlinks, and Flutter.framework under ios/. Updated CocoaPods, ensured all dependencies in pubspec.yaml are current. Added FirebaseCore initialization in AppDelegate.swift to resolve previous Firebase integration issues. Despite these efforts, the "Framework 'Flutter' not found" error persists. Here's the relevant part of my AppDelegate.swift and Podfile: swift import Flutter import UIKit @main @objc class AppDelegate: FlutterAppDelegate { override func application( _ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? ) -> Bool { GeneratedPluginRegistrant.register(with: self) return super.application(application, didFinishLaunchingWithOptions: launchOptions) } } ruby platform :ios, '14.0' CocoaPods analytics sends network stats synchronously affecting flutter build latency. ENV['COCOAPODS_DISABLE_STATS'] = 'true' project 'Runner', { 'Debug' => :debug, 'Profile' => :release, 'Release' => :release, } def flutter_root generated_xcode_build_settings_path = File.expand_path(File.join('..', 'Flutter', 'Generated.xcconfig'), FILE) unless File.exist?(generated_xcode_build_settings_path) raise "#{generated_xcode_build_settings_path} must exist. If you're running pod install manually, make sure flutter pub get is executed first" end File.foreach(generated_xcode_build_settings_path) do |line| matches = line.match(/FLUTTER_ROOT=(.*)/) return matches[1].strip if matches end raise "FLUTTER_ROOT not found in #{generated_xcode_build_settings_path}. Try deleting Generated.xcconfig, then run flutter pub get" end require File.expand_path(File.join('packages', 'flutter_tools', 'bin', 'podhelper'), flutter_root) flutter_ios_podfile_setup target 'Runner' do use_frameworks! use_modular_headers! flutter_install_all_ios_pods File.dirname(File.realpath(FILE)) target 'RunnerTests' do inherit! :search_paths end end post_install do |installer| installer.pods_project.targets.each do |target| flutter_additional_ios_build_settings(target) target.build_configurations.each do |config| xcconfig_path = config.base_configuration_reference.real_path xcconfig = File.read(xcconfig_path) xcconfig_mod = xcconfig.gsub(/DT_TOOLCHAIN_DIR/, "TOOLCHAIN_DIR") end end end Error Log from Flutter Run: [ +278 ms] Failed to build iOS app [ +42 ms] Error (Xcode): Framework 'Flutter' not found [ +8 ms] Error (Xcode): Linker command failed with exit code 1 (use -v to see invocation) [ +7 ms] Could not build the application for the simulator. [ +1 ms] Error launching application on iPhone 16 Pro Max. [ +6 ms] "flutter run" took 88,663ms. [ +164 ms] #0 throwToolExit (package:flutter_tools/src/base/common.dart:10:3) #1 RunCommand.runCommand (package:flutter_tools/src/commands/run.dart:860:9) #2 FlutterCommand.run. (package:flutter_tools/src/runner/flutter_command.dart:1450:27) #3 AppContext.run. (package:flutter_tools/src/base/context.dart:153:19) #4 CommandRunner.runCommand (package:args/command_runner.dart:212:13) #5 FlutterCommandRunner.runCommand. (package:flutter_tools/src/runner/flutter_command_runner.dart:421:9) #6 AppContext.run. (package:flutter_tools/src/base/context.dart:153:19) #7 FlutterCommandRunner.runCommand (package:flutter_tools/src/runner/flutter_command_runner.dart:364:5) #8 run.. (package:flutter_tools/runner.dart:131:9) #9 AppContext.run. (package:flutter_tools/src/base/context.dart:153:19) #10 main (package:flutter_tools/executable.dart:94:3) . Environment: Flutter: Version 3.27.3, Channel stable Xcode: Version 16.2, Build 16C5032a CocoaPods: Version 1.16.2 macOS: Version 15.2 (24C101) Additional Context: Initially, the issue was resolved by the sequence of cleanup and reinstalls listed above, but it re-emerged after integrating Firebase authentication. After adding FirebaseCore to AppDelegate.swift, the Firebase issue was resolved, but the framework error returned. I'm seeking guidance to resolve this issue permanently. Any insights or suggestions would be greatly appreciated!
1
0
427
4w
Can build my app but not Archive
Apologies that this is probably a simple problem. I've started from a sample code provided by Apple and changed it quite significantly. However, I'm not able to Archive the app. The original visionOS sample code has the same issue, so hopefully someone will be able to spot the problem: https://developer.apple.com/documentation/visionos/creating-stereoscopic-image-in-visionos The problems shown in the log are: Undefined symbol: _main Linker command failed with exit code 1 (use -v to see invocation) The first error seems to say that there's no "main" but there is indeed a @main in the EntryPoint.swift file. Any ideas? I have archived other apps (built from scratch) successfully, but clearly there's something different about this sample code. Many thanks!
6
0
320
4w
【Urgent/ Please help me out】Is it OK to encapsulate xcframeworkA into xcframeworkB (encapsulation of xcframework only)?
We are considering the development of a new service, We would like to ask for detailed information on the feasibility of the following. Is it possible to encapsulate only xcframework, such as encapsulating xcframeworkA into xcframeworkB? If the above is possible, will the application incorporating the xcframework in the above state pass the review of apple?
1
0
339
Jan ’25
IOS dylib to vision pro (Unity)
Hi, I am trying to bring an existing Unity app to vision pro, and am trying to make all of the librairies compatible (the project loads native libs at runtime). For some of them, there is an arm64 IOS .framework file that seems to build and be found easily in the device, but for one of them I only got a .dylib. When building on xcode, it tells me it can't find it. So I added it to the lib search path in build settings, and it built. But on the device, it still can't seem to find the .dylib : Library not loaded: ./libpdfium.dylib Referenced from: <59B1ACCC-FFFD-3448-B03D-69AE95604C77> /private/var/containers/Bundle/Application/0606D884-CB09-44CA-8E4F-4A309D2E7053/[...].app/Frameworks/UnityFramework.framework/UnityFramework Reason: tried: '/usr/lib/system/introspection/libpdfium.dylib' (no such file, not in dyld cache), './libpdfium.dylib' (no such file), '/usr/lib/system/introspection/libpdfium.dylib' (no such file, not in dyld cache), '//libpdfium.dylib' (no such file) I am not used to Apple environment, is there a way to correctly reference this .dylib (not talking about compatibility here, just the first "lib found" step) ? Thanks.
1
0
222
5d
Dynamic Links Not Working After App Installation
Hi everyone, I’m encountering an issue with Firebase Dynamic Links in my app that I’m hoping someone can help me with. Everything was working perfectly before, but recently, I’ve run into a problem. Here’s the scenario: If the app is not installed and a Firebase Dynamic Link is clicked, the user is correctly redirected to the app store to install the app. Once the app is installed and opened for the first time, the dynamic link doesn't work. The app doesn't open to the correct content or link that was clicked. I’ve tried the following troubleshooting steps with no success: Verified that the app is configured properly in Firebase and that the Dynamic Links settings are correct. Checked the app's deep linking settings and ensured everything matches with the Firebase setup. Confirmed that the Firebase SDK is up-to-date. Attempted to clear app cache and reinstall. Tested the links in both debug and production modes. Despite trying all these steps, the issue persists. Has anyone else faced this issue before or have any suggestions for how to fix it? Any insights would be greatly appreciated! Thanks in advance!
1
0
295
Jan ’25
Can Xcode still link with libcurl.{#}.tbd?
I created a new iOS project (storyboard if it matters) and added a bunch of C files to it. Some portion of the C files depend on libcurl. I would like to be able to build for both simulator and device if possible. Google claims that Xcode can provide the dependency as part of the inbuilt libraries however I do not see libcurl.4.tbd (or any version) as an option to choose. Is this feature no longer available or is there something I am missing here? For context here is a screen shot of my build error situation
4
0
354
Dec ’24
Unstable `archive` for `Debug` configuration (ld: file cannot be open()ed, errno=2)
We have a relatively big iOS-only project with around 80 build targets from swift packages (local features and external project dependencies) and Xcode 15.4 (originally, migrated to 16.0). Project compiles and runs great, but xcodebuild archive will fail 4 out of 5 tries with this: ld: file cannot be open()ed, errno=2 path=/opt/builds/fLLyxmhG/0/myapp/Build/Intermediates.noindex/ArchiveIntermediates/myapp (Development Flow)/BuildProductsPath/Debug-iphonesimulator/Account.o in '/opt/builds/fLLyxmhG/0/myapp/Build/Intermediates.noindex/ArchiveIntermediates/myapp (Development Flow)/BuildProductsPath/Debug-iphonesimulator/Account.o' Where Account.o is an end product of one of our feature packages linking to an .app itself. This error is not tied to this concrete package/product (which should be compiling almost last relative to build graph) and could appear mid-build in between our service layer packages. It seems (and is approved by Xcode timeline for .app archive log) that module dependency is compiled later than module itself and linker just cant find its dependency object files. The scheme is: Module A (dependency itself) Module B (needs module A) And with build order expected (???) to be A (first) -> B we're getting the B -> A. Error appears only when archiving for Debug configuration, archiving the same end-target with Release configuration results in stable passes 10 out of 10 tries. Setting identical parameters in Build Settings tab for both configurations of a target is not giving any effect. Our current fix is choosing Manual order in scheme Build order setting. Everything works as expected, but i guess it's not optimal 🤧 Sadly can't provide test project, but anything else — welcome.
0
1
294
Dec ’24
dyld assertation failure during linking w/ custom codegen
I am working on adding Objective-C ABI support to DLang and currently I'm getting the following error when linking with ld. Assertion failed: (fixups().size() == 1), function classTarget I'm curious as to why I am getting this error, looking at the objective-c runtime source, i have not applied any of the fixup flags to any protocol definitions. From my understanding, the source of the linker is not available so it's a bit on the difficult side to determine which part is wrong. The source of my pull-request is available here: https://github.com/ldc-developers/ldc/pull/4777
1
0
321
Nov ’24
iOS18 crash due to "main_executable_path_missing" and "dyld"
Our app experience the strange crash,causing the app to not launch.This crash suddenly began to happen on October 25. At present, all the Hardware Model of mobile phones that occurred were on iPhone17,1 and the iOS system version was iOS18.0.1. This crash was all from users on the appstore, and was collected via Xcode - Organizer - &gt; Crashes. I've attached the crash report.Thanks Distributor ID: com.apple.AppStore Hardware Model: iPhone17,1 Process: XxxxxxXXX [31230] Path: /private/var/containers/Bundle/Application/6E9E07EA-B7A4-4D57-B419-743DDCF7C3A6/XxxxxxXXX.app/XxxxxxXXX Identifier: com.XxxxxxXXX.XxxxxxXXX Version: 8.1.10 (811001) AppStoreTools: 16A242d AppVariant: 1:iPhone17,1:18 Code Type: ARM-64 (Native) Role: unknown Parent Process: launchd [1] Coalition: com.XxxxxxXXX.XxxxxxXXX [8069] Date/Time: 2024-10-31 03:30:38.7437 +0800 Launch Time: 2024-10-31 03:30:38.7415 +0800 OS Version: iPhone OS 18.0.1 (22A3370) Release Type: User Baseband Version: 1.00.00 Report Version: 104 Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: GUARD 5 Triggered by Thread: 0 Thread 0 Crashed: 0 dyld 0x00000001b2da32b0 lsl::PreallocatedAllocatorLayout&lt;278528ull&gt;::init(char const**, char const**, void*) + 436 (Allocator.h:537) 1 dyld 0x00000001b2d9ca38 start + 1960 (dyldMain.cpp:1289) Thread 0 crashed with ARM Thread State (64-bit): x0: 0x2010003030100000 x1: 0x0000000fffffc0d0 x2: 0x0000000000000002 x3: 0x00000001b2d717ab x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x2010003030100000 x9: 0x2010003030100000 x10: 0x000000016d1dbdfb x11: 0x00000001b2dddf30 x12: 0x0000000000000050 x13: 0x0000000000000044 x14: 0x0000000000052010 x15: 0x0000000000000000 x16: 0x0000000000000000 x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000018a7e0000 x20: 0x000000016d1dbb30 x21: 0x000000016d1dbad0 x22: 0x00000001f0794050 x23: 0x000000016d1db7b8 x24: 0x0000000fffffc10c x25: 0x0000000000000000 x26: 0x0000000000000000 x27: 0x0000000000000000 x28: 0x0000000000000000 fp: 0x000000016d1db850 lr: 0x00380001b2da3130 sp: 0x000000016d1db7b0 pc: 0x00000001b2da32b0 cpsr: 0x60000000 esr: 0x92000047 (Data Abort) byte write Translation fault Binary Images: 0x102c24000 - 0x1056d3fff main_executable_path_missing arm64 &lt;086a82c13b863f4485895baddc3144ba&gt; /main_executable_path_missing 0x1b2d69000 - 0x1b2dec693 dyld arm64e &lt;5db839882ee63756bd07b8d67b1133a5&gt; /usr/lib/dyld EOF 2024-10-26_17-41-58.4222_+0800-841f6bdf4b2d436606ce55595ffc94d64e9af744.crash 2024-10-26_19-44-40.1115_+0800-7d4d654c76a10108b431acc612d6063b1edb1c3e.crash 2024-10-27_17-12-02.4926_+0800-6a4b6ec4cff928cf746162b9371a3176c3667c21.crash 2024-10-28_21-42-02.6780_+0800-c66c71c13414e7ff14ba783c883730c1361523b5.crash 2024-10-29_05-47-00.3943_+0800-ac7c1f5b6caf9aa97d71744a8f980c32d47eab80.crash 2024-10-31_03-30-38.7437_+0800-e1c54dc8879f97932cbb1520a04210bea6d7aaf4.crash 2024-11-03_07-57-18.8892_+0800-c7704569afc79ce50ac10b66e185de87425b1969.crash 2024-11-03_08-27-19.0514_+0800-c069e2f8dfa6767b8e301513aff3c3a7ea331e2c.crash
1
0
691
Nov ’24
When application merges libswift_concurrency.dylib is duplicated in app binary
Environment: Xcode 16.1 Swift version: 6.0.2 Inside of an Xcode project, if I declare a framework and an application. The framework is mergeable and the application merges the framework by configuring MERGE_BINARY_TYPE to Manual (or automatic it's independent). If SWIFT_VERSION is set to 6.0.X and deployment target is set to iOS 15< the build is going to fail because of this error Duplicate linked dylib '@rpath/libswift_Concurrency.dylib' in '/Users/**/Library/Developer/Xcode/DerivedData/GSPackage-dvnngsrgctfovgfbvwdlsscfycyq/Build/Products/Debug-iphonesimulator/DummyApp.app/DummyApp.debug.dylib' If I'm checking the generated artifact and inspect all of it's @rpath with otool it's giving me the following: otool -L /Users/****/Library/Developer/Xcode/DerivedData/Dummy-gbccsjwxeajftsafghxzaqksgfim/Build/Products/Debug-iphonesimulator/Dummy.app/Dummy.debug.dylib | grep @rpath @rpath/Dummy.debug.dylib (compatibility version 0.0.0, current version 0.0.0) @rpath/libswift_Concurrency.dylib (compatibility version 1.0.0, current version 0.0.0, weak) @rpath/libswift_Concurrency.dylib (compatibility version 1.0.0, current version 0.0.0, weak) A radar is already opened with the ID: FB15693702
0
0
374
Nov ’24
Crash due to missing symbols from libc++ [macOS 11.7.10] [Big Sur]
We are seeing a crash on Big Sur 11.7.10 after switching the build system to use Xcode 15 Excerpt from crash Time Awake Since Boot: 1700 seconds System Integrity Protection: enabled Crashed Thread: 0 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Termination Reason: DYLD, [0x4] Symbol missing Application Specific Information: dyld: launch, loading dependent libraries Dyld Error Message: Symbol not found: __ZNSt3__17codecvtIDiDu11__mbstate_tE2idE Referenced from: /Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon Expected in: /usr/lib/libc++.1.dylib in /Applications/SecureworksTaegis.app/Contents/MacOS/com.secureworks.agent.daemon.app/Contents/MacOS/com.secureworks.agent.daemon Build system has the following specs : ProductName: macOS ProductVersion: 14.3.1 BuildVersion: 23D60 Xcode 15.2 Build version 15C500b CMAKE PROPS set(CMAKE_CXX_STANDARD 20) set(CMAKE_CXX_EXTENSIONS OFF) set(CMAKE_OSX_DEPLOYMENT_TARGET 11.0)
5
0
756
Nov ’24
Journaling Suggestions is not available on iOS Simulator
Hey, when I try to run my project on an iOS Simulator, I get the following message: JournalingSuggestions is not available when building for iOS Simulator. and Linker command failed with exit code 1 (use -v to see invocation) Steps to reproduce this behavior: Create a new Xcode project Add the Journaling Suggestions Capability Add the Journaling Suggestions Framework Under "Target > Build Phases > Link Binary with Libraries", select “optional“ for JournalingSuggestions.framework Under "Target > Build Settings > Other Linker Flags > Debug" select „Plus“ and add „iOS or iOS Simulator“ and paste this -Xlinker -weak_framework -Xlinker JournalingSuggestions into the editable field. Do the same for "Target > Build Settings > Other Linker Flags > Release" This tread is about the same problem, but is already checked as answered. That's why I'm creating this new tread. The last two bullet points are results from advice from the other thread. MacBook Air, M1, 2020, macOS: 14.6.1, Xcode: 16.0 Thanks for your help!
3
0
460
Oct ’24
Issues with Statsmodels
When I import starts models in Jupyter notebook, I ge the following error: ImportError: dlopen(/opt/anaconda3/lib/python3.12/site-packages/scipy/linalg/_fblas.cpython-312-darwin.so, 0x0002): Library not loaded: @rpath/liblapack.3.dylib Referenced from: &lt;5ACBAA79-2387-3BEF-9F8E-6B7584B0F5AD&gt; /opt/anaconda3/lib/python3.12/site-packages/scipy/linalg/_fblas.cpython-312-darwin.so Reason: tried: '/opt/anaconda3/lib/python3.12/site-packages/scipy/linalg/../../../../liblapack.3.dylib' (no such file), '/opt/anaconda3/lib/python3.12/site-packages/scipy/linalg/../../../../liblapack.3.dylib' (no such file), '/opt/anaconda3/bin/../lib/liblapack.3.dylib' (no such file), '/opt/anaconda3/bin/../lib/liblapack.3.dylib' (no such file), '/usr/local/lib/liblapack.3.dylib' (no such file), '/usr/lib/liblapack.3.dylib' (no such file, not in dyld cache). What should I do?
1
0
552
Oct ’24