Cocoapods: use_frameworks! results in pod not finding headers of its dependencies

[jcanizales]

Hi,

I have a pod A that depends on pod B. Both are C libraries. Pod B (which I don't own) has a directory structure like this:

/include/something/*.h
/src/<*.c and *.h, sometimes in nested dirs>

Includes are expected to be of this form #include <something/header1.h>, so B's podspec has:

s.public_header_files = 'include/something/*.h'
s.header_mappings_dir = 'include'

Without use_frameworks!, this works alright, because include/something gets put into the public headers folder with the appropriate links, and that folder is added to the search path. If the user sets use_frameworks! in his Podfile, though, the public headers links aren't created, nor added to the search paths, and thus compiling pod A fails.

I inspected the framework created for Pod B, and the headers are all flattened (there's no something directory inside). Changing #include <something/header1.h> into #include <B/header1.h> doesn't work for three reasons:

• It breaks the library if not using frameworks.
• It fails to build anyway because the generated B-umbrella.h header in the framework imports UIKit, which can't be built within a C library.
• Some of the headers of library B use the form #include <something/header1.h>.

Manually copying Pods/Headers/Public from a pod install without use_frameworks!, and adding "$(PODS_ROOT)/Headers/Public/B" to the search headers path of target A makes everything work again. Because I can't tell people to do the copying manually, I have to resort to the hack of adding "$(PODS_ROOT)/Headers/Private/B" (private!) to the headers search path in A's podspec, which works, but is all sorts of wrong.

Note: This also happens when both pods are Objective-C, except the generated umbrella header can import UIKit alright in that case.

Thanks a lot for your hard work!

[segiddins]

Can you share a project we can use to debug this? Thanks!

[jcanizales]

I've put four projects here that can be used to replicate the issue. It's the same toy app, varying whether it's written in Swift or ObjC, and whether the Podfile uses frameworks or not. They need git submodule --init update after cloning the repo.

While creating them I've realized there's no need of a pod that depends on another pod to replicate the issue, so I've simplified the case by just having the app depend on two pods, one in C and another in ObjC. Both pods work as static libraries, but fail as dynamic frameworks (no matter the language of the app).

[jcanizales]

Hi Samuel, are you able to replicate the issue?

[segiddins]

I've been busy with other things recently, but hopefully someone from the team will be able to investigate soon -- otherwise, we always accept PRs!

[jcanizales]

I'd be very happy to grab a book on Ruby and contribute; Cocoapods has been extremely useful to our users and us. But the problem is I don't know how this _should_ be solved: IIRC, removing the public headers under Pods/ in the case of use_frameworks! was a conscious decision.

Maybe module maps can be used to solve this? I'd need to get refreshed on them to be able and tell.

[balumusic2012]

how to Assign a captured image path to next view controller's UiimageView.
How can we get the total image data from stored image path to next view
controllers UIImageView?

On Sun, Nov 29, 2015 at 8:41 AM, Samuel E. Giddins <[email protected]

wrote:

Can you share a project we can use to debug this? Thanks!

—
Reply to this email directly or view it on GitHub
https://github.com/CocoaPods/CocoaPods/issues/4605#issuecomment-160362767
.

[balumusic2012]

how to Assign a captured image path to next view controller's UiimageView.
How can we get the total image data from stored image path to next view
controllers UIImageView?

On Tue, Dec 8, 2015 at 1:18 PM, Bala Bhaskar [email protected]
wrote:

how to Assign a captured image path to next view controller's UiimageView.
How can we get the total image data from stored image path to next view
controllers UIImageView?

On Sun, Nov 29, 2015 at 8:41 AM, Samuel E. Giddins <
[email protected]> wrote:

Can you share a project we can use to debug this? Thanks!

—
Reply to this email directly or view it on GitHub
https://github.com/CocoaPods/CocoaPods/issues/4605#issuecomment-160362767
.

[master-nevi]

Any updates on this?

[nikolay-kapustin]

For a new beta 1.0.0b also applicable.

[jcanizales]

I've investigated it and _it seems_ the problem can be solved by not generating the "Headers" (formerly "Copy Headers") build phase for the created targets, and not failing to create the Pods/Headers/Public directories.

I'm going to update the projects I linked above to reproduce the issue and, if those two measures solve it, I can try to make the changes in Cocoapods (although I'll need all the guidance in the world for that).

[matti777]

I'm facing the same issue, trying to build a Swift app using 'pod gRPC' as I need to use use_frameworks!.

Any ideas? I've spent the last few hours trying to build the grpc + dependencies into the project as source, but that is proving equally painful.

[matti777]

In the meanwhile I solved this by writing a shell script (which resides in the project root) that creates symlinks for the missing headers:

cd Pods/Headers/Private
ln -s BoringSSL/openssl/

for f in Protobuf/*.h
do
    ln -s $f
done

cd gRPC
ln -s ../Protobuf/google/

And also added a post_install hook to Podfile:

post_install do | installer |
  print "Running post_install hook to create symlinks..\n"
  system './create_symlinks.sh'
end

This is a "works for me" -solution, sure, but who knows, it or something similar might even work for You too.

[jcanizales]

Thanks for the report, Matti. To help me when I tackle this, can you check what version of Cocoapods you used?

[matti777]

The latest stable as of today, cannot remember the version any more since I already updated to 1.0.0-b6 which does the same thing.

Trying to build gRPC stack as a part of a Swift app using CocoaPods + use_frameworks!, basically.

EDIT: the versions tried were:

• 0.39.0
• 1.0.0.beta.6 (this one does not even create the header structure under Pods/Headers/Private)

[CapnSpellcheck]

Is there any update on this? I'm experiencing an issue on 0.39.0 where header for pod A are going entirely into Pods/Headers/Private, but that pod has public headers, and I'm developing pod B and now I really need to import an A header.

[atsepkov]

I too am experiencing this issue. It seemed to be fine in 0.39, at least until I specified an exact commit to pull for one of the libraries I was using. In the process I updated to 1.0.0.beta.6 and now my Pods/Headers directory is empty, removing use_frameworks! allows the directory to be populated, but as for others, breaks all Swift libraries. I've described the issue in more detail on Stack Overflow: http://stackoverflow.com/questions/36507504/pods-headers-empty-after-pod-install

[BenchR267]

Removing use_frameworks! is not really a solution :/

[jcanizales]

@TimBurks this is the issue.

[mfronczyk]

@matti777 I have a similar issue when trying to push my pod based on gRPC and I wanted to try your workaround, but I'm not sure where to execute the ./create_symlinks.sh during the build because I don't have Podfile, but Podspec, which doesn't have post_install. Can you help? My Podspec:

Pod::Spec.new do |s|
  s.name     = 'TestServiceApi'
  s.version  = '0.0.1'
  s.authors  = 'Michal Fronczyk
  s.homepage = 'https://bitbucket.org/jurand/milliongame-service-api-objc'
  s.summary  = 'gRPC test'
  s.license  = '...'
  s.source   = { :git => 'https://[email protected]/jurand/milliongame-service-api-objc.git', :branch => 'master' }

  s.ios.deployment_target = '8.0'
  s.osx.deployment_target = '10.9'

  # Run protoc with the Objective-C and gRPC plugins to generate protocol messages and gRPC clients.
  # You can run this command manually if you later change your protos and need to regenerate.
  s.prepare_command = "protoc --objc_out=. --objcgrpc_out=. *.proto"

  # The --objc_out plugin generates a pair of .pbobjc.h/.pbobjc.m files for each .proto file.
  s.subspec "Messages" do |ms|
    ms.source_files = "*.pbobjc.{h,m}"
    ms.header_mappings_dir = "."
    ms.requires_arc = false
    ms.dependency "Protobuf", "~> 3.0.0-beta-2"
  end

  # The --objcgrpc_out plugin generates a pair of .pbrpc.h/.pbrpc.m files for each .proto file with
  # a service defined.
  s.subspec "Services" do |ss|
    ss.source_files = "*.pbrpc.{h,m}"
    ss.header_mappings_dir = "."
    ss.requires_arc = true
    ss.dependency "gRPC", "~> 0.12"
    ss.dependency "#{s.name}/Messages"
  end
end

Solution can be found here - https://github.com/grpc/grpc/issues/6275#issuecomment-214911560

[dkharrat]

I'm seeing this issue too after upgrading to CocoaPods 1.0 (from 0.39.0), specifically for pod 'CocoaLumberjack/Swift' (I'm using a Swift project). The directive #import <CocoaLumberjack/CocoaLumberjack.h> does not work anymore. CocoaPods 0.39.0 did not have this issue. Seems like the difference between the two versions is that 0.39.0 generates the Pods/Headers/Private/... headers, whereas 1.0.0 does not.

It this a regression in 1.0?

[k06a]

Have the same issue with project created with pod lib create on 0.39.0. Test target can not find header:

.../Example/Tests/Tests.m:10:9: 'MyLib/MyLib.h' file not found

Here is project: https://github.com/k06a/DeluxeInjection/tree/feature/imperative
Tests can be compiled and passed if no use_frameworks! used, but gives a compilation error when use_frameworks! option is turned on.

[k06a]

Looks like this happens when pod lib create without example project, but with tests.

[prestonj]

I'm encountering the same problem in CocoaPods 1.0.0 and 1.0.1.

EDIT -- actually this problem exists in 0.39 too. My solution was to add to the xcconfig in the podspec as mentioned above (but also including all the potential platform variants that might exist:

  spec.xcconfig = {
    'USER_HEADER_SEARCH_PATHS' => '"${PODS_ROOT}/BrainCloudCpp/include"'
  }

Sadly I also had to do the same to another CocoaPod (BrainCloud) that depends on this one (BrainCloudCpp).

[k06a]

Found simple solution to disable and enable back option ALWAYS_SEARCH_USER_PATHS with pod install command between disabling and enabling again.

[robcecil]

I discovered the problem when using Cocoapods 0.39 !

My current solution is to only use Cocoapods with Grpc and any other ObjC
based pods. All swift Github frameworks that I need to use I handle with
Carthage.

On Wed, Jun 8, 2016 at 11:39 AM, Anton Bukov [email protected]
wrote:

Found simple solution to disable and enable back option of user defined
header search paths with pod install command between them.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/CocoaPods/CocoaPods/issues/4605#issuecomment-224629565,
or mute the thread
https://github.com/notifications/unsubscribe/ABdm5pmYkuN-3ABkVWXKilemRCOMKl3Hks5qJuIegaJpZM4Gq7XX
.

[k06a]

Updated ^^ comment with mentioning exact option ALWAYS_SEARCH_USER_PATHS to turn off, pod install, turn on and pod install again.

[dkharrat]

For my case, I noticed that this issue only happens when importing the pod in the bridging-header file. Removing it from the bridging-header file resolved the missing-include error. Note that it works fine in Cocoapods 0.39.

[chrisbull]

Someone please verify for me, but I think I discovered the fix. It's something to do with Xcode caching previous builds. I tried everything above, this was the only thing that worked for me. I realized that when i created a new project with the same pod modules, it built just fine. So I found it was something to do with my specific project.

The FIX ------------> Remove all builds from the directory: ~/Library/Developer/Xcode/DerivedData

And just to make sure things are set correctly, delete your Podfile.lock and Pods/directory.
And rerun pod install

[jcanizales]

Hi @chrisbull,

for gRPC's podspecs we've found a very hacky workaround. I'm releasing the new podspecs at the moment (version 0.14). The new version requires people to modify their local podspecs corresponding to their generated code; I'll be updating the documentation today.

For the general case, now that I understand Cocoapods' codebase better, I have an idea of how to fix it within Cocoapods. But right now I don't have the cycles to create a PR myself.

Cheers!

[donileo]

Having this issue as well.

[krypt-lynx]

Same issue in 1.0.1

[larssondaniel]

@chrisbull, this worked for me. Running 1.0.1

[pkieltyka]

cocoapods is some hacky piece of software

[pkieltyka]

hello, I spent a lot of time over the weekend trying to get CocoaPods 1.0.1 to build a very basic Swift+gRPC application. In my application, I stored the ".proto" files on the server (written in Go), where the proto files were in between different folders, to help be better organizes my messages/services there. Then, when using the ProtoCompiler pod to build the files, the pbobjc .m and .h files would be nested in folders, in the same structure as my server. That was all good and correct, except, clang couldn't find the header files of the generated pb pod. The problem was the folders, and so I tried everything I could find and think of to manipulate the search paths, but in the end I wrote a post-processor ruby script that runs after the ProtoCompiler pod is finished generated the objc pb code, that traverses the generated source and renames a path like "data/User.pbobjc.h" to "data_User.pbobj.h" and updates all of the sources -- essentially flattening the generated source. And this worked perfectly, and everything works great now. It's a bit hacky, but just another case to consider, perhaps this should be an option in the ProtoCompiler pod or something. Can pods have methods to call for these kinds of pre/post processors specific to their pod? ... otherwise, this works. If someone is interested in the solution let me know, or if they know of a more elegant solution..

[jcanizales]

Hi Peter,

please open an Issue for that in gRPC's repo. The Cocoapods guys can't help you with that problem (and they're probably not very willing anyway, given your previous message!).

Cheers!
Jorge

[randallli]

My errors went away when I removed header_mappings_dir usage in my subspecs.

When using header_mappings_dir with use_frameworks! in a swift project that specifies a subspec the generated Pods.xcodeproj will not have the the correct public headers. It looks like it was only making some of the headers public. It should be adding transitive dependency headers of another subspec too.

The bug only happens when I specify a subspec in my swift client app.

[atsakiridis]

We 're getting bitten by this too. Are there any plans to fix this? Seems applicable to all pods with non flat header structure when using use_frameworks!, so I guess it's pretty common, right?

I'd be happy to contribute a fix if you can give me some more details on what the problem is and guide me though the way to fix it.

Best regards,
Antonis

[jcanizales]

Hi Antonis:

I'm pretty sure the fix is a combination of this: https://github.com/grpc/grpc/issues/4121#issuecomment-222231908 and this: https://github.com/CocoaPods/CocoaPods/pull/6037

let me know if you have any questions: Even though I don't have cycles to write a fix myself, I've already dug into it so much that I'd be very glad to see it solved.

[atsakiridis]

Thanks @jcanizales let me get back to you when I get around to it

[texassiga]

After installing the CocoaPods. I saw a "Pods_appName" under Linked Frameworks and Libraries section. This is causing the build to fail. I am seeing following error "ld: framework not found Pods_appName". Removing this solves the problem but I don't understand this completely to decide if removing it is a good thing.

[CodeLife2012]

Any update?

[Skelzor]

A good workaround for me was to use Carthage for the Swift-Frameworks - it's much easier than to add all frameworks by yourself. But keep the possible problems in mind: StackOverflow

[javache]

We've split the react-native podspec into multiple podspecs and this is affecting us as well: https://github.com/facebook/react-native/issues/11781

The issue here seems to be that when use_frameworks is enabled we no longer create separate targets for every subspec but instead merge everything in one big target. This ignores any header_dir settings in subspecs.

To support frameworks, could we consider keeping the targets as-they-are but adding a framework target on top of that links the other static libraries?

[alloy]

As shown here https://github.com/facebook/react-native/pull/12089/files#diff-66230b3e029caa37b0fbdc8cbd47f4abR50, you can add a header search path to make this work.

[jcanizales]

@muxi: Per @alloy's fix, it looks like @dnkoutso's variable (of https://github.com/CocoaPods/CocoaPods/pull/6037) is already available, and we can undo our workarounds as commented in that PR?

[muxi]

Actually I am starting with it. The original way seems to be not working for now. I will update.

[sketch34]

Thanks for everyone's efforts in solving this issue. As a relative newcomer to cocoapods I'm having some trouble following this thread and understanding if:

a) There is a recommended workaround or fix? or...
b) Do I need to switch to a different system altogether like Carthage?
c) Is it possible to roll back to the previous cocoapods version 0.39.0 which worked?

I've just returned to a Swift project that I put on ice for a few months and this is blocking me after upgrading to the version recommended by the pod terminal.

pod --version = 1.1.1, was using 0.39.0.

Cheers all.

[pankkor]

any updates?

[DavidKuennen]

It's so sad that this is still not working. I was using CocoaPods just to include GoogleMaps and everything was broken afterwards.

[aaronbuchanan]

samesies @DavidKuennen

[segiddins]

It's so sad that this is still not working. I was using CocoaPods just to include GoogleMaps and everything was broken afterwards

This is open source. Complaining that something doesn't work perfectly is unproductive, and the most likely outcome is that you will de-motivate anyone on the team who otherwise would've looked at addressing the issue. If the issue is indeed critical for you, you're welcome to contribute a pull request that attempts to fix it, and I'm sure the team would be more than happy to review one, but merely commenting that you wish something had been done does not come off as appreciative for the project that is free for you to use.

Just my 2¢

[crontab]

Having tried everything above... what worked for me eventually:

Use the YourApp.xcworkspace file generated by cocoapds, not the YourApp.xcodeproj

This way the project file for Pods frameworks will be included and built too, and the headers will become available to your app.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

[stale[bot]]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem :+1:

[n8r0n]

I realize not everyone will want to go this route, but in a project I had control over the source code in, I worked around this problem by just removing the contents of the Bridging Header, and instead, in the Swift code that used my pods (which previously were#imported in the Bridging Header), I had an "Import LibName" that needed to be added in each .swift file.

See:
http://www.innerexception.com/2015/05/cocoapods-useframeworks-means-bridging.html

[matti777]

I notice this issue is still open. :) I am now using the following setup - in my FooService.podspec I have:

  s.pod_target_xcconfig = {
    # This is needed by all pods that depend on Protobuf:
    "GCC_PREPROCESSOR_DEFINITIONS" => "$(inherited) GPB_USE_PROTOBUF_FRAMEWORK_IMPORTS=1",
    # This is needed by all pods that depend on gRPC-RxLibrary:
    "CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES" => "YES",

    "USE_HEADERMAP" => "NO",
    "ALWAYS_SEARCH_USER_PATHS" => "NO",
    "USER_HEADER_SEARCH_PATHS" => "$(PODS_ROOT)/FooService",
    "HEADER_SEARCH_PATHS" => "$(PODS_ROOT)/FooService"
  }

And in the user target (the app using the gRPC pod) I simply add a User Header Search Path:

$(PODS_ROOT)/FooService

Still hacky.

• M

[heistings]

Any updates?

[fggeraissate]

As shown here https://github.com/facebook/react-native/pull/12089/files#diff-66230b3e029caa37b0fbdc8cbd47f4abR50, you can add a header search path to make this work.

@alloy This solution works for me 👍