`Pods` target has transitive dependencies that include static binaries

[rvi]

Hi,

Here is the error message I have when I'm doing a pod install :

pod install
Analyzing dependencies
Downloading dependencies
Installing CocoaLumberjack (2.0.0)
Installing CrashlyticsFramework (2.2.10)
Installing CrashlyticsLumberjack (2.0.1-beta)
[!] The 'Pods' target has transitive dependencies that include static binaries: (MY_iOS_app/Pods/CrashlyticsFramework/Crashlytics.framework)

I think I've got this error, because I'm forcing cocoapods to use frameworks.

I'm not sure, but maybe it's because we have s.dependency = 'CrashlyticsFramework' in the podspec ?
Regarding to this post on stackoverflow maybe we could try :

s.frameworks = 'CocoaLumberjack.framework'
s.vendored_frameworks   = "Dependencies/CocoaLumberjack.framework"

Any help is appreciate !

Here is my Podfile :

platform :ios, '8.1'
inhibit_all_warnings!
use_frameworks!

pod 'CocoaLumberjack'
pod 'CrashlyticsLumberjack', '=2.0.1-beta'

Pod version :

pod --version
0.37.1

[waltflanagan]

So, this is a problem because CrashlyticsFramework is a fake framework. It is a static library in a .framework container.

This was working with cocoapods 0.36 but they seem to have added more checks with 0.37 to catch more things like this.

For the most part, they're right. If a static library gets linked against multiple dynamic frameworks, we would end up getting duplicate symbols in each of those frameworks.

Unfortunately at this point, I don't see a way to support the integration of CrashlyticsLumberjack/Crashlytics via cocoapods using use_frameworks!

I suppose our best chance of getting this working is if Twitter publishes a dynamic version of Fabric/Crashlytics that could be intregrated using cocoapods this way.

For the time being, I would recommend pulling in the source files and just compiling them into your project along with the Crashlytics framework from twitter.

[rvi]

Thanks for this explanation ! :)

[pevasquez]

I agree that duplicate names due to duplicate library linking should be avoided, and so I see how this is a valid check for the linter to perform. I suppose these libraries are supposed to be added as Pods in the actual project.
But still, static libraries do have their advantages, and I don't see why pods depending on them should have their validation process truncated by this check.
Is it reasonable to request for the possibility to mark this dependency so the linter can check the validity of the podspec anyways (including for example, compilation), and in any case mark such a podspec with an error later on in the process?

Thanks!

[waltflanagan]

That sounds like a question for the Cococapods team. I don't have any control over what it considers an error.

[pevasquez]

Hah, I just landed here and don't know why I thought I was on Cocoapods' github. Sorry for this :)

[cbowns]

I'm also seeing this issue with CocoaPods 1.0.0.beta.3, when I add CrashlyticsLumberjack to my Swift project:

# git diff
diff --git a/Podfile b/Podfile
index 7d911f8..6791394 100644
--- a/Podfile
+++ b/Podfile
@@ -27,6 +27,7 @@ target 'app' do

   # Logging
   pod 'CocoaLumberjack/Swift', '~> 2.0'
+  pod 'CrashlyticsLumberjack', '~> 2.0'
 end

 # Pods for testing.

# pod install --verbose

…
Downloading dependencies

-> Using Alamofire (3.1.5)

-> Using BrightFutures (3.3.0)

-> Using CocoaLumberjack (2.2.0)

-> Using Crashlytics (3.6.0)

-> Installing CrashlyticsLumberjack (2.0.5)
  > Copying CrashlyticsLumberjack from `/Users/cbowns/Library/Caches/CocoaPods/Pods/Release/CrashlyticsLumberjack/2.0.5-bdcc5` to `Pods/CrashlyticsLumberjack`

-> Using Fabric (1.6.4)

-> Using NSData+FastHex (1.0.1)

-> Using Nimble (3.1.0)

-> Using Quick (0.9.0)

-> Using Result (1.0.1)

-> Using SimpleAlert (1.3.1)

-> Using Spine (0.2)

-> Using SwiftyJSON (2.3.2)

-> Using SwiftyUserDefaults (2.0.0)

-> Using Valet (2.2.0)
  - Running pre install hooks
[!] The 'Pods-app' target has transitive dependencies that include static binaries: (/Users/cbowns/Development/app/Pods/Crashlytics/iOS/Crashlytics.framework)

[williamsjj]

Since Crashlytics/Fabric now encourages using use_frameworks!, it would be great if this didn't trigger the transitive error anymore.

[sryze]

Any news on this? I'm getting the same error with CocoaPods 1.1.1.

[waltflanagan]

This is happening because Crashlytics.framework is distributed as a static library. This works fine for cocoapods targets that use it, but it breaks other pods that depend on linking against the framework when using use_frameworks! There are a few other pods out there with this same issue.

Solutions:

1. Crashlytics publishes a dynamic framework this can depend on.
2. Make a subspec without the dependency and force people to manually include the Crashlytics pod.

PRs welcome!