I'm assuming that LayerKit is only used via Atlas in this case? Could you also try what happens if you were to import and use LayerKit directly in the target app?

@neonichu Do you mean import it as a direct dependency also in the podfile?

@blakewatters No, I meant actually importing the module and using it inside the app directly.

We have a similar structure where one Pod of our app (ChatModule) depends on LayerKit, which contains a static binary.
This was working fine so far (though with evil hacks) but the latest CocoaPods update just forbids this behavior and we cannot build our project anymore.

Is there any reason this is an error instead of a warning??

PS: If I recall correct we link the static library to the app target and use -undefined dynamic_lookup in the ChatModule Pod.

PPS: We hope this is a temporary workaround until @blakewatters releases a dynamic framework version of LayerKit :)

We made this fail to front-load inevitable build failures, a warning that basically says "this will not build" would be weird :) It obviously shouldn't stop any working cases, though, so it might need to be even more specific.

eh sigh @neonichu you are correct — it’s having trouble resolving the Obj-C imports both within Atlas and if you directly import LayerKit. I’ll pull the source file workaround that prevented the build failure as its just moved it from Pod install time to build time.

What’s the remedy here? Do I need to declare Swift as unsupported until the packager can output dynamic frameworks?

Well, you can support Swift as long as your users are using a bridging header

On Mar 19, 2015, at 10:49 AM, Blake Watters <notifications@github.com mailto:notifications@github.com> wrote:

eh sigh @neonichu https://github.com/neonichu you are correct — it’s having trouble resolving the Obj-C imports both within Atlas and if you directly import LayerKit. I’ll pull the source file workaround that prevented the build failure as its just moved it from Pod install time to build time.

What’s the remedy here? Do I need to declare Swift as unsupported until the packager can output dynamic frameworks?

—
Reply to this email directly or view it on GitHub #3289 (comment).

@segiddins and are not integrating any Swift pods.

One way out could be moving the vendored LayerKit into the Atlas podspec directly, instead of a dependency, then it would all be linked into one dynamic framework.

Would building LayerKit as a dynamic framework improve the situation or is vendoring LayerKit such that it rolls up into one installable unit the only choice? I’m still trying to get my head around the exact problem space here as I haven’t done any Swift work yet

Pretty sure that building it as a dynamic framework is all that's needed.

Building as a dynamic framework would also eventually work, the vendoring approach was more a workaround suggestion.

At the moment, CP doesn't handle dynamic frameworks properly (see #1993) and there's possibly additional changes involved to make them work as transitive dependencies once that is done.

Until this issue is resolved we worked around the static library check by simply disabling it in the Podfile:

pre_install do |installer|
    internalInstaller = installer.installer
    def internalInstaller.verify_no_static_framework_transitive_dependencies; end
end

We can build again :)

Closing, as there is nothing for us to do here.

@fluidsonic how do you do pod lint? The error still happend

We're just using such a pod dependency and don't use pod lint.
I have no idea whether the workaround will work there.

fix for Podspec Podfile

    pre_install do |installer|
        def installer.verify_no_static_framework_transitive_dependencies; end
    end

@cooler333 are you sure it can be written in podspec? Can't make it work.

@k06a read again)

@cooler333 I am working on library that have a problem with dependency pod. And I have problems with pod spec lint. I need to fix it in podspec, not 'podfile'.

@k06a look at YandexMapKit Podspec.

how they integrate static library.

  "ios": {
    "vendored_libraries": "libYandexMapKit.a"
  }

I'm trying do the same in my swift library, but with no success.
If you fix this error, please, give me feedback.

@k06a Does You try to integrate sub pod with static library inside it?

My podspec have s.dependency 'PLCrashReporter' which have vendored_libraries inside itself. So my podspec can not be verified because of dependency issues.

@neonichu we are unable to have a dependencies with static libraries inside because can not manipulate installer.verify_no_static_framework_transitive_dependencies from a podspec. How we can solve our problem?

@orta, @neonichu why static libraries can not be statically linked with some stub pod target, which will produce dynamic framework while use_frameworks! is active?

It was not added to the latest cocoapod, which is 1.5 something

@fluidsonic Thanks

Thanks!!
I had same problem.

I publish a pod that requires apps to add this workaround to their Podfile. However, when I try to lib lint my pod, the build fails because of this issue.
Is there any way I can apply this workaround to "Pods-App" that is generated by lib lint?

Thank you @fluidsonic ❤️

I believe in the latest version of Pods it's not installer but install. That change (which Pods tells you about anyway if you had tried the installer version) works.

pre_install do |installer|
    internalInstaller = installer.installer
    def internalInstaller.verify_no_static_framework_transitive_dependencies; end
end

but:

pre_install do |installer|
    internalInstaller = installer.installer
    def internalInstaller.verify_no_static_framework_transitive_dependencies; end
end