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

FBSDKLoginKit can not find headers under 1.0.0 #4713

Closed
fcobia opened this issue Jan 2, 2016 · 20 comments
Closed

FBSDKLoginKit can not find headers under 1.0.0 #4713

fcobia opened this issue Jan 2, 2016 · 20 comments

Comments

@fcobia
Copy link

fcobia commented Jan 2, 2016

The 1.0.0 beta breaks the Facebook SDK. If you wither include the pod FBSDKCoreKit you can not reference the header files using "#import <FBSDKCoreKit/FBSDKCoreKit.h>."

If you include the pod FBSDKLoginKit, it will not compile because it can not access the FBSDKCoreKit headers.

I downgraded to 0.39.0 and it works with no errors.

@segiddins
Copy link
Member

Please share a project we can use to debug the issue :)

@fcobia
Copy link
Author

fcobia commented Jan 2, 2016

All you have to do is create an empty swift project and add "pod 'FBSDKLoginKit" to the Podfile.

I did create an empty project that you can see: https://github.com/fcobia/CocoaPodsTest

@segiddins
Copy link
Member

Thanks!

@neonichu
Copy link
Member

neonichu commented Jan 3, 2016

Took a quick look, seems like the issue is that the wrong copy headers build phases are being generated, e.g a "Copy .. Public Headers" which copies most of the SDK's headers into "$(PUBLIC_HEADERS_FOLDER_PATH)/.."

@neonichu neonichu added s2:confirmed Issues that have been confirmed by a CocoaPods contributor t2:defect These are known bugs. The issue should also contain steps to reproduce. PRs welcome! labels Jan 3, 2016
@segiddins
Copy link
Member

actually, Facebook’s podspec is wrong
it wouldn’t even lint using the beta
they have to push a new version with a fix
since they have headers that arent in the header_mappings_dir

@neonichu neonichu removed s2:confirmed Issues that have been confirmed by a CocoaPods contributor t2:defect These are known bugs. The issue should also contain steps to reproduce. PRs welcome! labels Jan 4, 2016
@neonichu
Copy link
Member

neonichu commented Jan 4, 2016

ah, totally missed that they are using header_mappings_dir somehow. Might make sense to warn/error in that case?

@segiddins
Copy link
Member

The linter already checks for that

@neonichu
Copy link
Member

neonichu commented Jan 4, 2016

👍

@segiddins
Copy link
Member

(Already as in, as of the 1.0 beta)

@neonichu neonichu closed this as completed Jan 4, 2016
@chrisp-fb
Copy link

Hi, I updated the header_mappings_dir one level higher which seems to resolve the issue initially,

pod 'FBSDKCoreKit', :podspec => 'https://raw.githubusercontent.com/chrisp-fb/facebook-ios-sdk/master/FBSDKCoreKit.podspec'

but it causes non-modular import errors with Cocoapods 0.39 (in a sample that uses FBSDKLoginKit and FBSDKShareKit as well)

"/Pods/FBSDKCoreKit/FBSDKCoreKit/FBSDKCoreKit/FBSDKAppLinkResolver.h:26:10: Include of non-modular header inside framework module ‘FBSDKCoreKit.FBSDKAppLinkResolver’ "

We've run into this before for different reasons (and it's odd that it breaks in 0.39). I tried a couple things include making Bolts an explicit of our LoginKit and ShareKit as well as removing header_mappings_dir in favor or proper private_header_files without luck. So, for now I'm going to simply set CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES to YES for our LoginKit and ShareKit specs to be compatible for both Cocoapods 0.39 and 1.0-beta2. Let me know if you have other ideas.

@neonichu
Copy link
Member

@chrisp-fb this might just be an instance of #4420

@chrisp-fb
Copy link

Interesting thread - but there's definitely something with header_mappings_dir as well; i.e., I'm using Xcode 7.2 consistently. Our current published podspec works fine with Cocoapods 0.39. It fails with Cocoapods 1.0-beta2 with the header_mappings_dir validation. So modifying the header_mappings_dir fixes it for Cocoapods 1.0-beta2 but then causes the non-modular import error in 0.39.

@neonichu
Copy link
Member

Yah, header_mappings_dir was deliberately changed for 1.0 since it was working inconsistently before, see #4267.

@cday
Copy link

cday commented Feb 27, 2016

@chrisp-fb Is there any anywhere I can track the work on this?

@btelintelo
Copy link

FBSDK was working for me in the Beta 1.0 release, but is now broken in the 1.0 release. I have FBSDKShareKit/CoreKit 4.11.0 installed but get the 'FBSDKShareKit/FBSDKShareKit.h' file not found

@Noobish1
Copy link

Having this issue as well with Cocoapods 1.0 and FBSDKCoreKit 4.12.0 and 4.11.0.

@hijamoya
Copy link

Having the same issue, please help!

@chrisp-fb
Copy link

I'm not able to reproduce the problem and am able to create and build a new swift app with a Podfile that installs all the FBSDK pods correctly. Can you file a report to developers.facebook.com/bugs with additional details like the Podfile and versions of all the tools you're using? If possible, try to include a sample project that reproduces the issue.

I'm using Xcode 7.3.1 and Cocoapods 1.0.0

@cday
Copy link

cday commented May 26, 2016

This appears to be some issue between CocoaPods and XCode. I tried to reproduce the problem I was seeing with a new project and was unsuccessful. Given that I tried removing the FBSDK from my project entirely. Once the FBSDK was removed I built and now a different Pod was failing to build due to a missing header. At this point I started digging through the active CocoaPod issues and found #4950. The solution seems to be remove all pods, nuke pod cache, nuke XCode's derived data for the project, and reinstall Pods.

TL;DR

rm -rfd *.xcworkspace
rm -rfd Pods
rm Podfile.lock
pod cache clean --all
rm -rfd ~/Library/Developer/Xcode/DerivedData/*
pod install

@samratshaw
Copy link

For people moving from Carthage to Cocoapods make sure to remove the Carthage references of the FBSDKCoreKit from the Link Binary With Libraries under Build Phases option.

screen shot 2017-07-27 at 1 41 26 pm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants