Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account


piercifani opened this Issue Nov 3, 2014 · 3 comments


None yet
3 participants
Copy link

piercifani commented Nov 3, 2014

There is a design flaw in CoreVideo.h that makes it really hard to build a framework with Xcode 6 and deploy it on apps that are still being built with Xcode 5. Details on this issues here and here.

The only way around this problem would be, according to people familiar with the matter, is to build the framework setting "Link Frameworks Automatically" set to no, which is currently impossible to do using Packager (amazing tool, I can't stress that enough).

I have set up sample repos that reproduce this issue for both a podspec called clever-framework and the Integrating app. In order to repo the issue, cd into the clever-framework and pod package it using Xcode 6. Then open the IntegratingApp.xcodeproj using Xcode 5, drop the framework you just compiled, try to archive the app and you'll see that if fails with the following linker error.

ld: framework not found Metal for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Where did Metal come you ask? See, AFNetworking needs CoreGraphics, which brings Metal into the picture. Don't believe me? Do a otool -arch armv7 -fl clever-framework to the framework's binary, you'll see this:

Load command 9
 cmdsize 32
   count 2
  string #1 -framework
  string #2 Metal

This bug is in reality a bad Framework design for Apple and we can work around it only setting the "Link Frameworks Automatically" to NO so the linker doesn't bring more frameworks than it should to the binary.

Thanks for hearing me out

PS: I manually added the compiled clever-framework.framework into the IntegratingApp repo and xcodeproj, so you can see this easily without bothering to compile the other repo.


This comment has been minimized.

Copy link

neonichu commented Nov 3, 2014

I see two options for supporting this in the packager:

  1. Allow custom post_install steps for the generated Podfile, so that one can manually change that option if needed.
  2. Generally set "Link Frameworks Automatically" to NO, as each specification should specify all the frameworks needed by it.

Thinking about option 2, I am wondering if even CP should set this option in the Pods.xcodeproj to avoid accidental linkage and make sure specifications are deterministic. @alloy any thoughts?


This comment has been minimized.

Copy link

alloy commented Nov 3, 2014

At least for the packager, I think it definitely makes sense to always set it to NO.

For CocoaPods itself, it would right now make sense, but I have had this lingering thought that we could maybe use it one day to simplify our use of xcconfig files. Having said that, it’s definitely a maybe/sometime kinda situation, so for now I think it makes sense to completely disable it.


This comment has been minimized.

Copy link

piercifani commented Nov 3, 2014

@neonichu With option Nº2 you mean only linking the frameworks specified in the podspec as dependant frameworks? That makes sense to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.