framework not found Metal for architecture armv7/armv7s

[mattyohe]

Surprising results from the last two builds you've provided (3.8.4, 3.8.5) when building with Xcode 5.1.1 via Cocoapods.

Even though your spec does not depend on Metal in the spec, the static library clearly depends on it, as seen if you run this:

otool -arch all -fl libCardIO.a

Results in output containing the below for each arch:

⋮
Load command 12
 519      cmd LC_LINKER_OPTION
 520  cmdsize 32
 521    count 2
 522   string #1 -framework
 523   string #2 Metal
⋮

[rhaining]

same here. i had to revert back to an older version to get this built.

[dgoldman-pdx]

Thanks, guys! We'll try to figure out why that dependence on Metal is showing up.

In the meantime, have you tried building using Xcode 6?

[dgoldman-pdx]

@mattyohe and @rhaining could you again try Xcode 5 + card.io 3.8.5? But this time in your project's Build Phases add these libraries (should work if they're marked as "Optional"):
* AudioToolbox
* AVFoundation
* CoreGraphics
* CoreMedia
* CoreVideo
* Foundation
* MobileCoreServices
* OpenGLES
* QuartzCore
* Security
* UIKit

For me, with our Sample App, that seems to work. If it still fails for you, try also turning off the Link Frameworks Automatically setting in Build Settings.

Let me know what happens...

[mattyohe]

@dgoldman-ebay So I was able to clone the repo and on master I was able to simply open up the sample app and build for device with no problems. Just seems to run into an issue when using this via Cocoapods.

[dgoldman-pdx]

@mattyohe How about your own app? Can you integrate the SDK into that one successfully?

The Sample App (as I discovered today!) explicitly lists its library dependencies, as listed in my comment above. So that might be why the Sample App worked for you, rather than anything directly related to CocoaPods.

If you manually add that list to your own app's project, what happens? If that solves things for you, we will update our podspec accordingly.

[mcyril]

@dgoldman-ebay , the same here:

ld: framework not found Metal for architecture armv7

xcode 5.1.1, "Link Frameworks Automatically" always disabled

[ignazioc]

same error for me.

[dgoldman-pdx]

@mcyril did you include the above list in your Link Binary with Libraries setting?

[dgoldman-pdx]

Ah-ha!

Okay, looks like I've found the source of the problem.

When building with the iOS 8 SDK, and a target of device (rather than simulator), both CoreVideo and OpenGLES bring in the Metal framework.

Here's the relevant section of CoreVideo.h:

#if COREVIDEO_SUPPORTS_METAL
#include <CoreVideo/CVMetalTexture.h>
#include <CoreVideo/CVMetalTextureCache.h>
#endif

where COREVIDEO_SUPPORTS_METAL is defined, basically, as #if TARGET_OS_IPHONE.

(I'm not sure where OpenGLES is bringing in Metal, but I see some indication that it is, too.)

So when we build our card.io SDK using Xcode 6 and the iOS 8 SDK, we end up with the Metal dependency.

I'd prefer to continue to build our latest SDK using the latest non-beta Xcode. Which implies that those of you still using Xcode 5 should continue to use version 3.8.3 of our SDK.

For you CocoaPods users, I'd love to update our podspecs to make this versioning automatic. But so far I don't see a way to specify a dependency on Xcode version or iOS SDK version. Any suggestions?

[mcyril]

sounds not so good, what could we do with backward compatibility? moving to Xcode 6 & iOS 8.0 SDK is not the equivalent to drop the iOS 7.x (and iOS 6.x) support in products. application which has been built even with recent non-beta(sic!) Xcode 6 will fail to run with iOS 7. thus the point not in the Xcode 5 usage.

usually the behaviour with defined IPHONEOS_DEPLOYMENT_TARGET with the version value less than current SDK's one did the trick. have you tried this way to build library? also at least Xcode could be forced to use -weak_framework with Metal.framework by explicitly defined OTHER_LDFLAGS with -weak_framework Metal (or status "Optional" in linked frameworks list in target general settings).

so the situation is following: I sure Apple will force developers to submit application build only with iOS 8.0 SDK (i.e. with Xcode 6) to AppStore (such things happened already). in this case Metal dependency have to be optional for backward compatibility for those who have sane minimum system requirements iOS 7 or iOS 6.1.

UPDATE: arrgh, Xcode 6 did the same trick described above with IPHONEOS_DEPLOYMENT_TARGET, looks like I have to move to Xcode 6 earlier than wanted.

[dgoldman-pdx]

@mcyril not to worry. This is all just a linker-time issue. At runtime everything should be compatible back to iOS 6. I.e., the linker has been demanding Metal, but at runtime Metal is not necessary (I've confirmed this by running successfully on an iOS 7 iPhone 4s.)

In any case, though, based on this discussion, I think that we now have a good build, suitable for Xcode 5 or 6, deployment target iOS >=6.

Please give version 3.8.6 a try and let me know how it goes.

[dgoldman-pdx]

Addendum: you may now have to explicitly add two more frameworks to your app's Link Binary with Libraries Build Phase: AudioToolbox and CoreMedia.

[mcyril]

@dgoldman-ebay thank you very much! works just fine. tested 3.8.6 with Xcode 5.1.1

[dgoldman-pdx]

Before I breathe a sigh of relief and close this issue, would appreciate hearing from a few others (@mattyohe? @rhaining? @ignazioc?) on whether version 3.8.6 solves the problem for them, too.

[hambly]

@dgoldman-ebay Thanks for the fix. Confirming that 3.8.6 fixed the metal dependency issue for me on Xcode 5.1.1, ios 7 deployment target.

[dgoldman-pdx]

Thanks, @hambly!

[kenworley]

FWIW, I had a similar problem caused by CocoaPods adding the Objc linker flag in my case. Removing the Objc linker flag and adding a force_load linker flag for the libPods.a library resolved the issue.

[yonido]

Hey, here's a blog post which summarizes this issue:
http://www.appsee.com/blog/dev/xcode-new-link-frameworks-automatically-fix-framework-not-found-metal-for-architecture-armv7

[EddyVerbruggen]

+1 for building the Estimote SDK with XCode 5 for the time being.

[dgoldman-pdx]

@EddyVerbruggen if you mean card.io rather than Estimote, then could you explain why you prefer to not update to Xcode 6 yet?

[EddyVerbruggen]

Oops I did mean Estimote, but rather posted this at the wrong repo.

Anyway the reason is that I'm using a cloud IDE (Telerik AppBuilder) which compiles its apps with XCode 5 (they're working on XCode 6 support of course). But for the time being any Cordova plugin wrapping the latest Estimote SDK (and card.io as well I reckon) doesn't compile because of the Metal linkage.

[dgoldman-pdx]

@EddyVerbruggen understood. Thanks!

(And card.io should be okay, actually, per the above-discussed fix.)