If I use the manual merge option with a mergeable library in debug mode, the app crashes on the device only. Here's what I found when debugging this issue. Problem situation 1 In the debug build, the linker does not find the type of the Meregeable Library. Explain the debugged result of Problem Situation 1 We have a type called UserAdDTO, which belongs to the B Framework. - In our project, B Framework and C Framework are mergeable libraries, and they are merged into A Framework. We are using Manual Merge in A Framework. When we build with the simulator, we link the UserAdDTO from CFramework.framework/CFramework in the app target. On the other hand, when I build with the device, I try to link it from AFramework.framework/AFramework, and I get the issue that UserAdDTO is not found. So, even if you output DYLD_PRINT_BINDINGS, the simulator build links to the C Framework to find the UserAdDTO, but the app links to the B Framework, causing a runtime crash. Problem situation 2 It is confirmed that only the device build does not copy the reexported binary. Detailed description of problem situation 2 If you compare the build messages from the device build with the build messages from the release build, both generate the reexported binaries of B and C Frameworks, but do not copy them to BFramework.framework and CFramework.framework. Instead, they copy the files in different paths. This appears to be a bug, and I'd like to ask you to confirm.

So I'm working on a large client app with lots of frameworks and modules which is is a mix of Xcode frameworks with 3rd party dependencies in CocoaPods and newer/converted SPM modules. Essentially CocoaPods is used to set the 3rd party dependencies on various Xcode frameworks, which also depend on each other via manual set dependencies, plus a bunch of SPM modules which are also manually added. It's a bit of a mess. The problem we encountered the other day started when I added a new protocol to one of the SPM modules. Nothing special about it, all types from Foundation and the app built and ran perfectly in simulator with a Debug build. However when we switched to building a Release build, it failed to link, logging an error indicating it could not resolve the new protocol in a number of the Xcode framework projects. The resolutions go like this: The Xcode app project has some manually added Xcode frameworks. Those frameworks have manually added dependencies on a second Xcode framework. That second framework has an SPM dependency on the module where my protocol lives. So Xcode App -> 1st Xcode framework -> 2nd Xcode framework -> SPM module. Now the 2nd Xcode framework directly uses my protocol from the SPM module. But the 1st Xcode framework neither uses or imports the SPM module. Yet the error we get when building for Release is that the 1st Framework is unable to resolve the protocol from the SPM module even though it's completely oblivious to it. My working theory is that something in the way a Release build works is insisting that when linking the 1st Xcode framework, it has to resolve the 2nd Xcode framework, which then has to resolve types from the SPM modules, but for some reason and only in a Release build, it's unable to. So our current workaround has been to add the SPM module as a dependency to all 1st level Xcode frameworks that have the 2nd Xcode framework as a dependency. That works because when linking the 1st Xcode framework, it has a direct reference to the module even though the code never imports anything from it. Does this should correct?

ld: symbol(s) not found for architecture arm64 clang++: error: linker command failed with exit code 1 (use -v to see invocation) Undefined symbol: nominal type descriptor for CoreGraphics.CGFloat Undefined symbol: type metadata for CoreGraphics.CGFloat Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.BinaryFloatingPoint in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.Encodable in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.FloatingPoint in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.Hashable in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.Comparable in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.Equatable in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.Decodable in CoreGraphics Undefined symbol: protocol conformance descriptor for CoreGraphics.CGFloat : Swift.SignedNumeric in CoreGraphics

We have updated our cross-platform applications to support iOS 18 and are in the final stages of releasing versions built with MacCatalyst. After merging the MacCatalyst changes with those for iOS 18, we are now required to build the app using Xcode 16. However, since transitioning to Xcode 16, the app builds successfully but crashes immediately on startup with the following error: dyld[45279]: Symbol not found: _$sSo22VNFaceLandmarkRegion2DC6VisionE16normalizedPointsSaySo7CGPointVGvg Referenced from: <211097A0-6612-3A9A-80B5-AE12915EBA2A> /Users/***/Library/Developer/Xcode/DerivedData/DM_iOS_Apps-gzpzdsacfldxxwclyngreqkbhtey/Build/Products/Debug-maccatalyst/MyApp.app/Contents/Frameworks/Filters_MyApp.framework/Versions/A/Filters_MyApp Expected in: <50DB755E-C83C-3FC7-A0BB-9C4DF9FEA374> /System/Library/Frameworks/Vision.framework/Versions/A/Vision This crash occurs only when building the app with Xcode 16 for MacCatalyst on macOS 14.6.1. On iOS and macOS 15, it functions as expected, and it also worked prior to the iOS 18 changes, which are independent of the Vision framework code, when building with Xcode 15. Here are the environment details where the error occurs: Xcode Version: Xcode 16.0 (16A242d) macOS Version: macOS Sonoma 14.6.1 And the setup where it works: Xcode Version: Xcode 16.0 (16A242d) macOS Version: macOS Sequoia 15.0 Additionally, attempting to implement a workaround using pointsInImage(imageSize:) resulted in a similar issue, where the symbol for this method is also missing. Is this a known issue? Are there any workarounds or fixes available? We have already submitted this issue as feedback (FB15164375), along with a demo project to illustrate the problem.

On Xcode Version 15.3 (15E204a), the project builds successfully without any errors. However, on Xcode Version 16.0 (16A242), I encounter the errors mentioned below. ld: 1 duplicate symbol for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Additional Context: Faced same issue earlier and fixed: Add "-ld64" under Build Setting -&gt; Other Linker Flags

I am having an issue with Xcode 15 when I create an archive build of my application. The general structure I something like: Main Application: Links to staticLib.a Plugins: use datatypes in staticLib.a When I build an archive build and load the bundle for the plugin, I get the following type of errors: Error Domain=NSCocoaErrorDomain Code=3588 "dlopen(pluginBinary, 0x0109): symbol not found in flat namespace '_OBJC_CLASS_$_FIRST_MISSING_CLASS'" This program runs fine and finds the plugins without issues if I run the program from Xcode. It also will run and find the plugins correctly if I build a release build using xcodebuild. Only if I use Archive does it fail to load these files in the flat namespace. The plugins and the main binary say they use the TWOLEVEL namespace using otool -hV on them. If I link the static library to the plugin, I get undefined behavior because both are linking to the same binary. The plugins are using: -undefined dynamic_lookup in their linker flags. Any ideas how to resolve this? Thanks, Steven

Note that I am trying to build my project for IOS 18 using XCode version 16 Beta 6. I have version 18.0 of the iOS beta installed on my iPhone. My project includes pods for Firebase and GRPC-Core. I ran pod update and it installed Firebase (11.1.0), BoringSSL-GRPC 0.0.36, OpenSSL-Universal 3.3.1000, and gRPC-Core 1.65.5. When I try to build my project I encounter the following error: Undefined symbol: _c2i_ASN1_INTEGER This symbol is not referenced in my code. It's unclear which pod references this symbol - although Firebase is a likely candidate. Is anyone else encountering this issue? I'm wondering if I could safely go back to a version of Firebase that does, as the previous version I had installed (10.22.0) didn't have this issue.

I'm working on a Payment SDK integrating Storekit2 for Unity games. The workflow is as follows: build the swift project that exposes objective c interface to static libraries, then archive them into xcframework embed the xcframework into native unity plugin where we call objective-c functions from C# export the unity project to Xcode project build the game Xcode project When deployment target of swift project is set to iOS15 No matter what iOS version target is set in the game Xcode project, I got build error: Undefined symbol: __swift_FORCE_LOAD_$_swiftCompatibility56 When deployment target of swift project is set to iOS16 And set the deployment target of game project to iOS15 (I need to let the payment sdk to work on iOS15 as Storekit2 and swift concurrency shipped with iOS15). I can build the game Xcode project, and it works on iOS16+ device. But when I run on iOS15 device, I got runtime error: 2024-08-26 18:17:29.289078+0900 ***[1404:95780] Error loading /var/containers/Bundle/Application/123/***/Frameworks/UnityFramework.framework/UnityFramework: dlopen(/var/containers/Bundle/Application/123/***/Frameworks/UnityFramework.framework/UnityFramework, 0x0109): Symbol not found: (_objc_claimAutoreleasedReturnValue) Referenced from: '/private/var/containers/Bundle/Application/123/***/Frameworks/UnityFramework.framework/UnityFramework' Expected in: '/usr/lib/libobjc.A.dylib' 2024-08-26 18:17:29.418604+0900 ***[1404:95780] Error loading /var/containers/Bundle/Application/123/***/Frameworks/UnityFramework.framework/UnityFramework: dlopen(/var/containers/Bundle/Application/123/***/Frameworks/UnityFramework.framework/UnityFramework, 0x0109): Symbol not found: (_objc_claimAutoreleasedReturnValue) Referenced from: '/private/var/containers/Bundle/Application/123/***/Frameworks/UnityFramework.framework/UnityFramework' Expected in: '/usr/lib/libobjc.A.dylib' If I chose not to build framework into static libraries but dynamic ones, I can avoid this problem but Unity cannot handle dynamic libraries well when exporting to Xcode project so I have no choice here but to stick to static ones. minimum reproduction I made a minimum reproduction project to exclude the process of unity. a fresh new empty objective-c app project embed the xcframework built with target iOS15 call a function in the framework in applicationDidFinishLaunch set the deployment target of main target of the app project to iOS15. build the project I still get Undefined symbol: __swift_FORCE_LOAD_$_swiftCompatibility56 versions Xcode version 15.4 Test iOS device version 15.8

We have a cross platform app that we build with Xcode Cloud and distribute via TestFlight. We want to test builds with the Xcode Beta. So we have the following build environment: Xcode version: Xcode 16 beta 6 (16A5230g) macOS Version: macOS Sonoma 14.5 (23F79) Everything builds and submits to TestFlight fine. The App runs fine on iOS 18 beta and macOS 15 beta. But when attempting to install via TestFlight and launch the App on macOS 14..6.1 it crashes immediately with what appears to be a missing Foundation symbol. Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace DYLD, Code 4 Symbol missing Symbol not found: _$s10Foundation14NSDecimalRoundyySpySo0B0aG_SPyADGSiSo14NSRoundingModeVtF Referenced from: <CBEBC813-C7B6-3D8E-BE62-16F2EFFEB1FE> /Applications/MyApp.app/Contents/MacOS/MyApp Expected in: <2F87A303-430F-3EA5-9492-3033F4FEE64B> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (terminated at launch; ignore backtrace) Thread 0 Crashed: 0 dyld 0x7ff8139f687a __abort_with_payload + 10 1 dyld 0x7ff813a0f7f7 abort_with_payload_wrapper_internal + 82 2 dyld 0x7ff813a0f829 abort_with_payload + 9 3 dyld 0x7ff81399c2b5 dyld4::halt(char const*, dyld4::StructuredError const*) + 335 4 dyld 0x7ff8139994bd dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 4099 5 dyld 0x7ff8139982e4 start + 1812 Is it expected that this should work? Is this a known issue? Is there any workaround for it? Should I file feedback or a DTS?

When I configured the mergeable library manual and ran a build on the device, I got a runtime crash. However, when I build on the simulator, I don't get a runtime crash. This only happens when I build on the device. I was wondering if this is a bug? The error message is shown in the attached picture. Build environment XCode 15.3 I built in debug mode. The CoreToolKit target is manually merged with the rest of the targets. The app target links to the CoreToolKit target. The app target is not linked to the targets that are merged into the CoreToolKit target.

I have existing code in production that links against the mach-o library, and uses the following code: NSData *data = [NSData dataWithBytes: getsectiondata(&_mh_execute_header, "__TEXT", "__somePlist_plist", &len) length:len]; In order for this to compile with Sequoia Beta 4 and Xcode 16 beta 4, I have to replace _mh_execute_header with _mh_dylib_header. If I don't, the compiler raises the following error: ld: Undefined symbols: __mh_execute_header, referenced from: -[MyClass init] in MyClass.o clang: error: linker command failed with exit code 1 (use -v to see invocation) Any idea why the linking behavior might have changed? Should I file a bug? (I realize this is a C issue, not Objective-C - but didn't find a tag for that) Thanks!

I'm attempting to determine whether there is a currently logged on user via the SCDynamicStoreCopyConsoleUser function. My code look something along the lines of: #include &lt;SystemConfiguration/SystemConfiguration.h&gt; bool isUserLoggedOn() { CFStringRef name = SCDynamicStoreCopyConsoleUser(NULL, NULL, NULL); if (name != NULL) { CFRelease(name); return true; } return false; } I am getting the following error output on compilation: Undefined symbols for architecture arm64: "_CFRelease", referenced from: isUserLoggedOn() in UserInfo.cpp.o "_SCDynamicStoreCopyConsoleUser", referenced from: isUserLoggedOn() in UserInfo.cpp.o ld: symbol(s) not found for architecture arm64

I am building my project and it build failed on Xcode 16.0 Beta 2 use Default linker(I think it's -ld_new). Undefined symbols for architecture arm64: "__mh_execute_header". But when using the -ld64 linker, this error will not be reported. I am confused. Does -ld_new have any special handling for __mh_execute_header? Thanks for any help!

I've been working on a Swift PM wrapper for the libtiff library, which I installed on my Mac via Brew. So far so good. But I just tried adding it to my visionOS project. and it complained that it was trying to link against a library built for macOS: building for 'visionOS-simulator', but linking in dylib (/opt/homebrew/Cellar/libtiff/4.6.0/lib/libtiff.6.dylib) built for 'macOS' I wish Brew would build universal libraries, but it doesn’t, and they have no interest in doing so. What are my options? If I build libtiff from sources, it’s still a bit of a pain to build against a different SDK. libtiff has its own Makefile I’d rather not try to edit. Can I make an xcframework out of it? Can I statically link it into my Swit wrapper library? Do I need to hack together a C build target in my Package and copy the source files over to it?

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!

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

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?