My project built successfully with Xcode 7 beta 4, but with Xcode 7 beta 5 I now get this error when linking to an existing framework (pre-built i386 binary, I don't have the source code): ld: building for OSX, but linking in object file built for (unknown)What changed in the linker? I didn't see anything in the release notes. How can I continue to link to this framework?
Search results for
Building for iOS Simulator, but the linked and embedded framework ‘XX.framework‘ was built for
186,331 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
That worked for me, thanks.I have a framework project, with example targets inside, for iOS, macOS and tvOS. In the example projects I had to remove the framework from the embedded binaries and from the linked frameworks and libraries, then copied the entire framework's source code into the Example projects, converted the Examples to Swift 4, then removed the code and added the framework as it was initially.I'm using Xcode 9 GM
Topic:
App & System Services
SubTopic:
Core OS
Tags:
I had to set up the following Build Settings, to make my custom framework work. Excluded Architectures Debug -> Any iOS Simulator SDK: arm64 Release -> Any iOS Simulator SDK: arm64
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
This is not true. I have 2 framework targets that are targeted at their respective devices (watchOS and iOS). Each has their module name set to the same name. As long as you link them correctly within the appropriate embedded binaries, they do compile the correct frameworks and are copied into the /Frameworks directory of the appropriate targets. There's no reason you can't have them named the same at all, they don't search in the same paths or link to the same locations.
Topic:
App & System Services
SubTopic:
General
Tags:
I am having a similar issue with the GM. I don't know if it existed before as I was waiting for the GM before using Xcode 7.ld: in /Users/dctrotz/Projects/MyAppName/src/3rdParty/openssl/lib/libcrypto.a(cryptlib.o), building for iOS simulator, but linking in object file built for OSX, for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
I have a app that is using the Nuance Dragon Dictation SpeechKit framework that is causing the following warnings:Object file (/Users/jeffsullivan/Documents/Projects/iOS 7 Migration (branch)/Platt Electric/SpeechKit.framework/SpeechKit(libSpeechKit.a-armv7-master.o)) was built for newer iOS version (9.0) than being linked (7.0)andObject file (/Users/jeffsullivan/Documents/Projects/iOS 7 Migration (branch)/Platt Electric/SpeechKit.framework/SpeechKit(libSpeechKit.a-arm64-master.o)) was built for newer iOS version (9.0) than being linked (7.0)My minimum target is set for iOS 7.0 and I have turned off bitcode for the project. It seems to work properly, but I'd rather not have warnings if I can avoid them. Does nayone have any input on what the cause of this could be?Thanks
I am using UI tests to test an embedded framework. I have enabled 'gather code coverage' of both the app target and the framework target and used @testable import my framework in my test files.After running all the UI tests on an iPhone 6s simulator, all the framework files have 0% code coverage while the app files have good coverage.What are the steps to enable code coverage for frameworks or is this a bug?Using Xcode 7.2.1
Hi,I have the following problem - Mac app has embedded framework with app and framework configured as separate targets of the same project. Build settings for app and framework follow this Technote 2435 https://developer.apple.com/library/content/technotes/tn2435App builds just fine with framework located inside the app bundle. More to that: app runs just fine from Xcode and Finder. The problem is that destributing app to a different user or copying it to another user account which doesn't have access to app's build directory produces this crashCrashed Thread: 0Exception Type: EXC_CRASH (SIGABRT)Exception Codes: 0x0000000000000000, 0x0000000000000000Exception Note: EXC_CORPSE_NOTIFYTermination Reason: DYLD, [0x1] Library missingApplication Specific Information:dyld: launch, loading dependent librariesDyld Error Message: Library not loaded: /Users/USER/*/XYZ.framework/Versions/A/XYZ Referenced from: /Users/USER/*/Awesome.app/Contents/MacOS
When running in debug mode from Xcode with debug session active, the app launches in the simulator and I am able to debug.When trying to launch the app in the simulator without debug session (by double clicking on the icon), it crashes with the log message below.Everything is fine on the real device.This makes it impossible for me to debug Apple Watch apps, since the iOS version of the app cannot be launched in the background from the Apple Watch.I am running Xcode 7 beta 3, but I don't think it is a bug, I am probably missing som flag in build settings. Any help is appreciated.Application Specific Information:dyld: launch, loading dependent librariesDYLD_FALLBACK_LIBRARY_PATH=/Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/libDYLD_ROOT_PATH=/Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdkDYLD_FALLBACK_FRAMEWORK_PATH=/Applications/Xc
I am able to build this on simulator but when built on device facing crash in this line let areActivitiesAllowed = ActivityAuthorizationInfo().areActivitiesEnabled Using iOS 16 beta 4. Anyone facing same? For simulator push token is nil. How can we test this?
Topic:
App & System Services
SubTopic:
General
Tags:
We're also experiencing this when running the following command: xcodebuild -workspace ios/ExampleApp.xcworkspace -scheme ExampleApp -destination 'generic/platform=iOS Simulator' -configuration Debug -derivedDataPath ios/build The way I read this error is that a XCFramework that we're using is built for 86_64 but the iOS Simulator launched is 64. I can't understand why something that's built for both 86 and 64 doesn't work for an 64 device. Maybe using another iOS Simulator device or version (and 86 one, maybe an older simulator) would work??? Does anyone else make more sense of that error?
Topic:
Developer Tools & Services
SubTopic:
Xcode
Tags:
I just got this warning too, in Xcode 15.0 (15A240d) on macOS Sonoma 14.0 (23A344): ld: warning: building for 'macCatalyst', but linking in dylib (/Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa.tbd) built for 'macOS' ld: warning: building for 'macCatalyst', but linking in dylib (/Applications/Xcode-15.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL.tbd) built for 'macOS'
Topic:
Developer Tools & Services
SubTopic:
General
Tags:
Description My iOS project supports app clips, and both the iOS app and that embedded app clip are using same dynamic framework but different versions. To be more detailed, iOS app uses the full list of features in that dynamic framework, while app clips uses the trimmed features which aims to remove the package size according to the app clip size limitation. The project works fine in Xcode 12.4. However, when we try to build it with Xcode 13.2.1, below compile error is reported. Multiple commands produce '{{ Path-To-App-Installation }}/MyDynamicFramework.framework/Headers': 1) Command: ProcessXCFramework {{ Path-To-iOS-App-Xcode-Project }}/MyDynamicFramework-v2.0/MyDynamicFramework.xcframework {{ Path-To-App-Installation }}/MyDynamicFramework.framework ios simulator 2) Command: ProcessXCFramework {{ Path-To-iOS-App-Clip-Project }}/MyDynamicFramework-v1.0/MyDynamicFramework.xcframework {{ Path-To-App-Installatio
This is definitely new in beta 5; I had no problems linking in beta 4.I don’t think this is related to the framework binary being universal, as I thinned it with lipo and am still getting the same message:% lipo -info /Library/Frameworks/Growl.framework/Growl Non-fat file: /Library/Frameworks/Growl.framework/Growl is architecture: i386Ld /Users/nicholas/Library/Developer/Xcode/DerivedData/Pester-dmqwzzanlsudtshkfhcnikgvqgcr/Build/Products/Debug/Pester.app/Contents/MacOS/Pester normal i386 [...] ld: building for OSX, but linking in object file built for (unknown), file '/Library/Frameworks/Growl.framework/Growl' for architecture i386It looks like somehow the linker is expecting the OS information, not architecture, to be embedded in the binary and not finding it?I also saw some suggestions that this may be related to code signing, so I re-signed the framework but this did not appear to affect anything:% codesign
Topic:
Developer Tools & Services
SubTopic:
General
Tags:
>>> you would do better to create the 12 libraries as static libraries, and use an Xcode target to link them into a single dynamic framework. Thanks for the quick reply. I was trying the exact same thing with a sample swift FrameworkA built as Static Framework(Changed Mach-O Type to static library) trying to link in a dynamic framework FrameworkB. Then tried to integrate with a Test app. It works on my macbook pro, but the moment I send that app to another machine, it complains Missing required module 'FrameworkA' in that which means the umbrella framework is not exactly embedding the FrameworkA but just links it. Only option I have found till now, is to deliver both Static Framework and Aggregate dynamic framework to end-user which is inconvenient for the users and defeats the purpose of having an umbrella dynamic framework. That was the reason for my question, as what the Apple recommended ap
Topic:
Programming Languages
SubTopic:
Swift
Tags: