I used to have a static library, I turned it into a dynamic library, which was more difficult than I expected. I already had a small project, containing a command line tool which loads a dynamic library. This was created direct from Xcode 15.3's macOS app and dynamic library templates. This is how I configured the Dynamic Library Install Name Base to @rpath. Note that there is nothing in the Dynamic Library Install Name target setting, but it resolves to @rpath/libCLI_library.dylib. If I click on it once, I can see the value I click on it again to see how this value is generated The expression it is generated from is $(LD_DYLIB_INSTALL_NAME_$(LLVM_TARGET_TRIPLE_VENDOR):default=$(EXECUTABLE_PATH)) Using a Run Script phase I can see the environment variables, which include LLVM_TARGET_TRIPLE_VENDOR = “apple”, and LD_DYLIB_INSTALL_NAME_apple = “@rpath/libCLI_.dylib” If I look at the environment variables in my other dylib project, which started life as a static library, although LLVM_TARGET_TRIPLE_VENDOR is set to "apple", there is no LD_DYLIB_INSTALL_NAME_apple variable at all, so even if I paste the expression above into the LD_DYLIB_INSTALL_NAME setting, it does me no good, because it evaluates to EXECUTABLE_PATH, which is libXXX.dylib, but I'd like @rpath/libXXX.dylib. So my question are, where does LD_DYLIB_INSTALL_NAME_apple come from? where does the magic invisible expression for Dynamic Library Install Name come from? the quick help for Dynamic Library Install Name mentions "if this option is not specified, the -o path will be used" - what build setting is that?

I have a third party library added to my project as ThirdParty.framework, but it only supports real device. I want to make my project still build for simulators but exclude this library and any references of importing it. I tried a few things, for example in the target's build phase "Link Binary With Libraries" set this framework as "Optional", and in the code I have: #if !targetEnvironment(simulator) import ThirdParty class SomeClass: ProtocolFromThirdParty { // ... } #endif Also some view that has reference to this class: import SwiftUI #if targetEnvironment(simulator) struct TestViewSimulator: View { var body: some View { Text("See this view on real device") } } #else struct TestView: View { @StateObject var example = SomeClass() var body: some View { // ... } } #endif But still when I build for simulator, it still gives error for the linking issue: Building for 'iOS-simulator', but linking in object file (/<Path>/ThirdParty.framework/ThirdPartySDK[arm64][2](someobject.o)) built for 'iOS' Building to a real device works as expected. Any suggestions I could make it build on simulators? (I'd like to isolate this screen only for real device and not impacting other parts of the app)

Hello, I get a lot of crashlogs from MetricKit watchdog on iOS 17.5.1 all related to dyld. Does anybody has the same issue or any idea what could be the problem? Attached is the Crashlog. wathchdog exhausted real (wall clock) time allowance of 30.00 seconds ProcessVisibility: Background ProcessState: Running WatchdogEvent: process-launch. crash in dyld process Following error is shown: 0 Thread 0 1 dyld objc::findhash(dyld3::OverflowSafeArray<objc::bstuff, 4294967295ull>&, unsigned int*, unsigned long long*, unsigned int*, unsigned int, dyld3::OverflowSafeArray<objc::PerfectHash::key, 4294967295ull>&) + 584 2 dyld objc::PerfectHash::make_perfect(dyld3::OverflowSafeArray<objc::PerfectHash::key, 4294967295ull>&, objc::PerfectHash&) + 124 3 dyld objc::PerfectHash::make_perfect(dyld3::OverflowSafeArray<char const*, 4294967295ull> const&, objc::PerfectHash&) + 152 4 dyld dyld4::PrebuiltObjC::generateHashTables(dyld4::RuntimeState&) + 128 5 dyld dyld4::PrebuiltObjC::make(Diagnostics&, dyld4::RuntimeState&) + 2968 6 dyld dyld4::PrebuiltLoaderSet::makeLaunchSet(Diagnostics&, dyld4::RuntimeState&, dyld4::MissingPaths const&) + 468 7 dyld dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 2920 8 dyld start + 1724 MetricKitLog.txt

I've been given an Xcode project which produces a command line tool which links to a dylib. I have the dylib, but not its source code. I change the signing option for the command line tool target so it is signed automatically by my personal team. On an attempt to run the tool, it fails to load the dylib, because the dylib is signed with a different certificate. I manually codesign the dylib with the same certificate I am using for the command line app. Now, I can build the app, but not run it. If I try to do so, I see four dialogs telling me “libXXX.dylib” can’t be opened because Apple cannot check it for malicious software, then the console tells me "'/path/to/libXXX.dylib' not valid for use in process: library load disallowed by system policy)" I found an old document about Gatekeeper (https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html) which suggests that Gatekeeper just won't let me do this - I can't just put the dylib next to the executable, although the dynamic linker finds the dylib, Gatekeeper doesn't like it because the dylib isn't inside the app bundle (there is none), and isn't in one of the well-known places. I dealt with this by making a do-nothing app which I can sign with my personal certificate. Then I replace the signature on the dylib (and its dependent dylibs) with my own. I add the command line tool and all its dylib dependencies to the do-nothing app, then add those files into the Copy Bundle Resources phase of the do-nothing app. Now, the command line tool and its dylibs all live in do-nothing.app/Contents/Resources, and I can run the tool from there without Gatekeeper complaining. Is there an easier way (aside from asking my supplier for static libraries)? And if this is the only way, is Contents/Resources the right place to put command line tools and the dylibs they link to?

I'm trying to compile a little project in C with the following structure: Project | |-&gt;Headers |-&gt;library.h | |-&gt;src |-&gt;main.c |-&gt;library.c I've checked all my files, my configurations files and I'm getting the same error everytime, someone could please help me? :( Undefined symbols for architecture arm64: "_getfavoritenumber", referenced from: _main in main-99c109.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

I have an iOS SwiftUI app which uses some extensions like NotificationServiceExtension, NotificationContentExtension, WidgetExtension etc. I noticed that each extension uses its own process and has its own bundle with the .appex extension... and is packaged within the app bundle, with .app extension. In my case, most of my logic is in C++ and when the app starts up, it needs to 'startup' the C++ layer. Now, in WidgetExtension, if it's going to read data from disk and update its interface, I need to initialise my C++ layer first. The same can be said for NotificationServiceExtension. This is leading me to include all my C++ artefacts into the extension target as well. Here's my problem: If the size of my app (containing all my C++ artefacts) is 10MB and I'm using 20 extensions (say), the final size of the shipped app bundle is 10MB + (20 * 10MB) = 210MB, since extension bundle (.appex) is packaged within the app bundle (.app). Since the app and the extensions are using the same C++ artefacts, I was hoping to have one binary in the bundle. The app and its extensions will point to this binary. When the app is launched, the app entry point (struct conforming to App protocol) is invoked, in case of widget, the widget entry point (WidgetBundle) is invoked and so on for each extension. This will reduce the final size of the app bundle. Is it possible to have one binary and the app target, all extension targets would use this binary for there functioning?

It seems impossible to me, but around the time I installed the latest command line tools (xcode-select version 2397) binaries what were built with linkages to @rpath/libfoo.dyld stopped being able to find their dependency. The error looks like this. dyld[1471]: Symbol not found: _GEOSGeomGetX Referenced from: <16DBE67F-CB32-31EE-BCE0-BFB58EEC9740> /Users/pramsey/tmp/capi_indexed_predicate Expected in: <no uuid> unknown zsh: abort ./capi_indexed_predicate If I turn on DYLD_PRINT_SEARCHING, I can see the linker giving up on the rpath entry. dyld[1501]: find path "@rpath/libgeos_c.1.dylib" dyld[1501]: not found: "@rpath/libgeos_c.1.dylib" I can work around, partially, by setting DYLD_LIBRARY_FALLBACK_PATH to have /usr/local/lib in it, but that is only a partial fix, because SIP will strip that variable for any child processes, which means most of my development and database work is borked. This seems like a very new quirk, maybe related to the XCode 15 update, at least in my personal time line, has anyone else seen it, or have any clue as to what has changed? (Worth noting, nothing changed in my code, just one day my builds wouldn't run anymore, and that day was the day after I had installed the new commandline tools).

Hello Apple Developer Community, I am currently working on an xCode project that uses Objective-C and I am trying to integrate Apple's external purchase link APIs available in iOS 15.4. To use these APIs, I need to utilize async and completion handlers which are available from iOS 13 onwards. The issue I'm facing is that the current minimum deployment version for my project is iOS 12. I would like to ensure my code compiles properly for the correct iOS versions and I am also using #if available; to ensure this. However, I am unsure of how to guarantee my code builds effectively with the deployment version being set to either iOS 12 or 13. I am currently facing the following linker errors: ld: warning: Could not find or use auto-linked library 'swiftCompatibility56': library 'swiftCompatibility56' not found ld: warning: Could not find or use auto-linked library 'swiftCompatibilityConcurrency': library 'swiftCompatibilityConcurrency' not found ld: warning: Could not find or use auto-linked library 'swiftCompatibilityPacks': library 'swiftCompatibilityPacks' not found ld: Undefined symbols: __swift_FORCE_LOAD_$_swiftCompatibility51, referenced from: __swift_FORCE_LOAD_$_swiftCompatibility51_$_ProjectXYZ in ProjectXYZ.a[20](ExternalPurchaseLinkWrapper.o) __swift_FORCE_LOAD_$_swiftCompatibility56, referenced from: __swift_FORCE_LOAD_$_swiftCompatibility56_$_ProjectXYZ in ProjectXYZ.a[20](ExternalPurchaseLinkWrapper.o) __swift_FORCE_LOAD_$_swiftCompatibilityConcurrency, referenced from: __swift_FORCE_LOAD_$_swiftCompatibilityConcurrency_$_ProjectXYZ in ProjectXYZ.a[20](ExternalPurchaseLinkWrapper.o) clang: error: linker command failed with exit code 1 (use -v to see invocation) I would appreciate any guidance or advice on this matter. How do I ensure my code compiles and works only for the correct versions and how do I resolve the linker errors? Thank you in advance for your assistance. Best, Sumanth

Xcode version: 15.2, iOS deployment target 15.0 When experimenting with the new Xcode 15/new linker feature "Mergable Libraries" I came across an issue with subproject framework products. I have a workspace with two projects. I want to create a group framework named GroupFramework that consists of three other frameworks. FrameworkA, FrameworkB and FrameworkC. FrameworkA and FrameworkB are in the same project as the group framework I want to create. FrameworkC is a product of another project in my workspace. GroupFramework has all three frameworks linked in the "link binary with libraries" build phase. GroupFramework has "Create merged binary" set to manual because I want to control which frameworks are linked. FrameworkA, FrameworkB and FrameworkC all have "Build mergeabe library" set to YES. The application builds in both RELEASE and DEBUG. Running in DEBUG and RELEASE When running the application on a device in DEBUG or RELEASE it crashes with a linker error because FrameworkC can't be found on disk. When inspecting the app binary in RELEASE I can see that FrameworkA and FrameworkB are both in the ReexportedBinary folder, but FrameworkC is nowhere to be seen. I have tried embedding FrameworkC explicitly in the settings of the GroupFramework essentially creating an umbrella framework, and that also does not fix the issue. I have also tried embedding FrameworkC directly into the AppTarget that will consume GroupFramework. This solves the linking issue but a new issue regarding unresolved symbols then crops up. It appears as though the Reexporting and Merging of subproject frameworks is not working compared to a product that exists in the same project or at least may require a lot more manual configuration which is not currently documented anywhere. If this is the case, it could be very problematic when trying to adopt mergeable libraries in multi-project workspaces.

I am wondering where the source code of ld-prime is on Github. There are references to it in the github for dyld, but I can't find it anywhere. I have a suspicion that it uses LLVM for linking. I'm looking out of curiosity to see if Apple is slowly closing down its compile toolchain and maybe learn how Apple sped up the linking stage.

The documentation about the Disable Library Validation Entitlement mentioned that the macOS dynamic linker (dyld) provides a detailed error message when the system prevents code from loading due to library validation. You can find more information here: https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_disable-library-validation I need assistance in locating the dynamic linker (dyld) on macOS Ventura 13.0. What are the various methods available to locate it? How can I access or open it for reading? Additionally, do I need any external tools to facilitate this process? My ultimate goal is to examine the detailed error message to identify any issues I am encountering with my application. Additionally, I have found one at /usr/lib/dyld, but it's not human-readable, nor does it have timestamps for whatever is logged. Based on my findings, I should be able to locate dyld at System/Library, but I can't find it there either.

Hi Everyone, This is my first post here. I am a student looking for answers, and I would like to know how to use libraries such as the ones mentioned in the title. How do I link them? I have tried every method under the sun, but I cannot get Xcode to find the file I am trying to include.

I'm doing the python dynamic module loading dance. As you likely know, this is not the typical shared library scenario described on all the docs, where an executable is linked against an existing shared lib. Instead cythonized python modules need to call back to the interpreter that loaded them for various functions. Thus, when creating the interpreter, some manner of symbol export must happen, which can then later be linked into a module's dynamic lib to resolve interpreter symbols. With GNU/GCC this is all magic with the -shared flag (perhaps GNU's weak symbol feature, unsupported on macOS, helps out?). With a MingW GCC variant on Windows -Wl,--output-def python.def is required, followed by dlltool -d python.def -l python.dll.a, which creates some object thingy that can be linked into the subsequent module .so files. I played with lipo python -create -output libpython.dylib on macOS, but saw that no one else uses this and abandoned it. The python3 on Darwin uses clang -bundle -undefined dynamic_lookup, but when I roll my own custom interpreter, building a module by hand with the above gives: ld: warning: -undefined dynamic_lookup may not work with chained fixups ... whatever that means. Link args of -bundle -bundle_loader ../python result in NO errors or warnings, but my interpreter cannot load these module .so files either, probably due to some error I have not yet unmasked. I am hoping to find a solution that works for both Xcode and Homebrew, and that will last for a decade or so, but for now would be happy getting something to work today.

xcode15.2 showing error, Unkown option: -no_warn_duplicates_libraries

Xcode 15.2 linker error (Assertion failed: (rebasePtr->target == low56), function writeChainEntry, file ChainedFixups.cpp, line 1218) The same project builds fine on Xcode 14.3.1. It also builds fine when building a debug build to device. Any ideas on what we might be doing wrong?

Hello everyone, Our iOS app is taking too long to launch. On checking the launch profile, we are seeing that most of the launch time is being spent in applying fixups which is taking more than a second and at times even more to complete. Our deployment target is iOS 15+. We have checked using dyld_info that our binary uses chained fixups. Since chained fixups are enabled, page-in linking should also be enabled for our app as per this WWDC session. Can someone please help us understand why the fixups application is taking this long and how can we improve it? Thanks.

Hi, I am splitting my iOS app into smaller components, the natural way of doing this is to create static libraries that I can link with the main binary. I did succeed at making small static libraries (.a) and link them, but I was struggling with static framework where I have color assets. Finally I was able to make it work by going to the app target > Build Phases > Copy Bundle Resources and add there the .xcassets from the static framework I created. The confusion on my side is that the assets are accessed from the Framework code not from the app target code, and the guidance I am asking for is: How to create and link a static framework on iOS so that the framework can load and use it's own defined assets without having to do the Copy Bundle Resources step. Best Regards, Ion

Hi everyone, Our app runs on iOS deployment target 15.0. As per the WWDC 2022 session, page-in linking should be enabled for apps where chained-fixups is enabled. Since chained fixups are enabled from iOS deployment target 13.4+ which is true for our app, will page-in linking be applied to it? Is there some flag which we can use to confirm if it is applied for our app or not? We have tried using dyld_info tool but could not find a command which can provide this information.

I have a React-Native App that I am trying to build to iOS using Xcode. When I build to my iPhone 12 Mini (iOS 17.4.1), the app works perfectly. When I build to my iPhone 7 Plus (iOS 15.8.2), the app pauses running immediately, and Xcode displays the following in the log: dyld[935]: Symbol not found: (_JSGlobalContextSetInspectable) Referenced from: '/private/var/containers/Bundle/Application/2579192B-74C5-4B54-AA59-948C49A4A7CA/MANHUNT2.app/MANHUNT2' Expected in: '/System/Library/Frameworks/JavaScriptCore.framework/JavaScriptCore' The app used to work perfectly on both phones, but this error has been happening recently, and I am unsure of the cause. Cleaning build folder and deleting derived data has not fixed the issue. Xcode: Version 15.3 React-Native: 0.73.6 Working Phone: iOS 17.4.1 Non-Working Phone: iOS 15.8.2

I have the XCode Version 15.3 (15E204a). When I try to compile my application, the following errors occur: Undefined symbol: _GDTCCTConstructiOSClientInfo Undefined symbol: _GDTCCTNetworkConnectionInfoNetworkMobileSubtype Linker command failed with exit code 1 (use -v to see invocation) Any solution to fix this issue?