Wrong LIBRARY_SEARCH_PATHS after updating pods

[ghost]

I had Podfile in my project with CardIO pod. I've added new pod to the file and run pod install, what caused updating of all pods in the project. After updating I got the error while building my project:

Undefined symbols for architecture i386:
  "_OBJC_CLASS_$_CardIOPaymentViewController", referenced from:
      objc-class-ref in AddCreditCardViewController.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

After comparing current version of project with previous one I've figured out that Library Search Paths are set, but project somehow can't find this path (this path is not shown in Build Settings):

Then I've compared new and old version of Pods.xconfig:

Old version:

#include "Pods-AFNetworking.xcconfig"
#include "Pods-BMUtilityPack.xcconfig"
#include "Pods-CardIO.xcconfig"
#include "Pods-Foursquare-API-v2.xcconfig"
#include "Pods-PaymentKit.xcconfig"
#include "Pods-SBJson.xcconfig"
#include "Pods-SVProgressHUD.xcconfig"
#include "Pods-Stripe.xcconfig"
ALWAYS_SEARCH_USER_PATHS = YES
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1
HEADER_SEARCH_PATHS = "${PODS_ROOT}/Headers" "${PODS_ROOT}/Headers/AFNetworking" "${PODS_ROOT}/Headers/BMUtilityPack" "${PODS_ROOT}/Headers/CardIO" "${PODS_ROOT}/Headers/Foursquare-API-v2" "${PODS_ROOT}/Headers/PaymentKit" "${PODS_ROOT}/Headers/SBJson" "${PODS_ROOT}/Headers/SVProgressHUD" "${PODS_ROOT}/Headers/Stripe"
LIBRARY_SEARCH_PATHS =  ${PODS_CARDIO_LIBRARY_SEARCH_PATHS}
OTHER_LDFLAGS = -ObjC ${PODS_AFNETWORKING_OTHER_LDFLAGS} ${PODS_CARDIO_OTHER_LDFLAGS} ${PODS_SVPROGRESSHUD_OTHER_LDFLAGS} ${PODS_STRIPE_OTHER_LDFLAGS}
PODS_ROOT = ${SRCROOT}/Pods

New version:

FRAMEWORK_SEARCH_PATHS = "$(PODS_ROOT)/Google-Maps-iOS-SDK"
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1
HEADER_SEARCH_PATHS = "${PODS_ROOT}/Headers" "${PODS_ROOT}/Headers/AFNetworking" "${PODS_ROOT}/Headers/BMUtilityPack" "${PODS_ROOT}/Headers/CardIO" "${PODS_ROOT}/Headers/Foursquare-API-v2" "${PODS_ROOT}/Headers/Google-Maps-iOS-SDK" "${PODS_ROOT}/Headers/Google-Maps-iOS-SDK/GoogleMaps" "${PODS_ROOT}/Headers/PaymentKit" "${PODS_ROOT}/Headers/SBJson" "${PODS_ROOT}/Headers/SVProgressHUD" "${PODS_ROOT}/Headers/Stripe"
LIBRARY_SEARCH_PATHS = "$(PODS_ROOT)/CardIO/CardIO"
OTHER_LDFLAGS = -ObjC -lCardIO -lc++ -licucore -lz -framework AVFoundation -framework AudioToolbox -framework CoreData -framework CoreGraphics -framework CoreLocation -framework CoreMedia -framework CoreText -framework CoreVideo -framework Foundation -framework GLKit -framework GoogleMaps -framework ImageIO -framework MobileCoreServices -framework OpenGLES -framework QuartzCore -framework Security -framework SystemConfiguration -framework UIKit
PODS_ROOT = ${SRCROOT}/Pods

Adding `#include "Pods-CardIO.xcconfig"`` line resolved this problem, but this will fix it only until next install/update.

[fabiopelosin]

Is this issue still relevant?

[ghost]

Yes, I've updated CocoaPods and after updating pods in the project still having same issue.

[fabiopelosin]

So for other reasons we are not using the includes anymore:

How the paths in the Pods-CardIO.xcconfig differ from following search paths?

LIBRARY_SEARCH_PATHS = "$(PODS_ROOT)/CardIO/CardIO"

[ghost]

Here is the content of Pods-CardIO.xcconfig:

PODS_CARDIO_LIBRARY_SEARCH_PATHS = "$(PODS_ROOT)/CardIO/CardIO"
PODS_CARDIO_OTHER_LDFLAGS = -lCardIO -lc++ -framework 
AVFoundation -framework AudioToolbox -framework CoreMedia -framework
CoreVideo -framework MobileCoreServices -framework OpenGLES -framework 
QuartzCore -framework Security -framework UIKit

Path is the same.

[fabiopelosin]

It looks like your target is defining the LIBRARY_SEARCH_PATHS setting. If this is the case you should clear it so the settings of the Xcconfig can be used.

[ghost]

LIBRARY_SEARCH_PATHS in target settings was set to ${PODS_CARDIO_LIBRARY_SEARCH_PATHS} after updating CocoaPods.

Removing this setting or changing it to $(PODS_ROOT)/CardIO/CardIO doesn't help.

I don't understand, why adding #include "Pods-CardIO.xcconfig" to Pods-CardIO.xcconfig helps, because Pods-CardIO.xcconfig has the same path in PODS_CARDIO_LIBRARY_SEARCH_PATHS

[ghost]

Also setting $(PODS_ROOT)/CardIO/CardIO as LIBRARY_SEARCH_PATHS and adding adding #include "Pods-CardIO.xcconfig" to Pods-CardIO.xcconfig fixes it.

[fabiopelosin]

LIBRARY_SEARCH_PATHS in target settings was set to ${PODS_CARDIO_LIBRARY_SEARCH_PATHS} after updating CocoaPods.

I strongly doubt it because we don't touch the settings of the user target. That is what the xcconfig is for.

Removing this setting or changing it to $(PODS_ROOT)/CardIO/CardIO doesn't help.

Try clearing the setting in your target and then copy and paste the contents of the Pods-CardIO.xcconfig file to the top the Pods.xcconfig instead of using the import. This should work, then I would suggest to delete each setting to understand which one is the required one.

[yvbeek]

@irrationalfab Would it be possible (with a small CocoaPods design change) to prevent changes to so many files when you add or remove a pod?

As described in this issue: adding a pod causes all the xcconfigs to change their HEADER_SEARCH_PATHs, quite distracting in a code diff.

I understand the need for flexibility, can't we reduce the number of files and duplicate definitions a bit?

For example: I have one target with the TestFlight pod and one without. All the xcconfigs are exactly the same for the second target. Would it be possible to say: heck just use the same xcconfig unless I have defined a xcconfig (overwrite) for that target-pod?

[yvbeek]

Perhaps we could set a recursive HEADER_SEARCH_PATH and use symbolic folder links? Something like:

HEADER_SEARCH_PATH="$PODS_ROOT/$TARGET/HEADERS/**"

Target A:
A/HEADERS/Pod1 --> HEADERS/Pod1

Target B
B/HEADERS/Pod1 --> HEADERS/Pod1
B/HEADERS/TestFlight --> HEADERS/TestFlight

[jonsterling]

I am also having trouble getting my project to build which uses the Card.io podspec (linker errors). Any ideas?

[lshemesh]

I am a complete newb when it comes to iOS development, but I managed to get my project to build by changing the architectures I was building against, for both the Pods library as well as my main project. That was a while ago though so I can't remember which I ended up removing. I recommend playing around with those values in your build settings.

[derpoliuk]

@jonsterling I've updated CocoaPods to version 0.28, removed Pods folder, Podfile.lock and Projectname.xcworkspace files and installed pods again.

Now I'm having issue with categories in pods, so this issue with LIBRARY_SEARCH_PATHS might be fixed for me.

UPD:

I've deleted all Pods and .xcworkspace file again, run pod install again and have no issues with categories.

This is how variables in the project look (in XCode for my target, I've checked Project.xcodeproj/project.pbxproj file but there's multiple definitions of this variables, not sure wich one is right):

HEADER_SEARCH_PATHS = $(inherited)
OTHER_LDFLAGS = -ObjC, $(PODS_CARDIO_OTHER_LDFLAGS)
LIBRARY_SEARCH_PATHS is empty.

And I still having this issue. Once again adding #include "Pods-CardIO.xcconfig" to Pods.xcconfig and setting LIBRARY_SEARCH_PATHS to $(inherited) in project settings fixes this problem.

UPD2:

Try clearing the setting in your target and then copy and paste the contents of the Pods-CardIO.xcconfig file to the top the Pods.xcconfig instead of using the import. This should work, then I would suggest to delete each setting to understand which one is the required one.

@irrationalfab I did it. Required setting is:

PODS_CARDIO_OTHER_LDFLAGS = -lCardIO -lc++ -framework AVFoundation 
-framework AudioToolbox -framework CoreMedia -framework CoreVideo 
-framework MobileCoreServices -framework OpenGLES 
-framework QuartzCore -framework Security -framework UIKit

Pods.xcconfig:

FRAMEWORK_SEARCH_PATHS = "$(PODS_ROOT)/Google-Maps-iOS-SDK"
GCC_PREPROCESSOR_DEFINITIONS = $(inherited) COCOAPODS=1
HEADER_SEARCH_PATHS = "${PODS_ROOT}/Headers" "${PODS_ROOT}/Headers/AFNetworking"
"${PODS_ROOT}/Headers/BMUtilityPack" "${PODS_ROOT}/Headers/CardIO" 
"${PODS_ROOT}/Headers/FSOAuth" "${PODS_ROOT}/Headers/Foursquare-API-v2" 
"${PODS_ROOT}/Headers/Google-Maps-iOS-SDK" 
"${PODS_ROOT}/Headers/Google-Maps-iOS-SDK/GoogleMaps" 
"${PODS_ROOT}/Headers/MBProgressHUD" "${PODS_ROOT}/Headers/PaymentKit" 
"${PODS_ROOT}/Headers/SBJson" "${PODS_ROOT}/Headers/SVProgressHUD" 
"${PODS_ROOT}/Headers/Stripe" 
"${PODS_ROOT}/Headers/UrbanAirship-iOS-SDK"
LIBRARY_SEARCH_PATHS = "$(PODS_ROOT)/CardIO/CardIO"
OTHER_LDFLAGS = -ObjC -lCardIO -lc++ -licucore -lsqlite3.0 -lz -framework AVFoundation 
-framework AudioToolbox -framework CFNetwork -framework CoreData -framework CoreGraphics 
-framework CoreLocation -framework CoreMedia -framework CoreTelephony -framework CoreText 
-framework CoreVideo -framework Foundation -framework GLKit -framework GoogleMaps 
-framework ImageIO -framework MapKit -framework MessageUI -framework MobileCoreServices 
-framework OpenGLES -framework QuartzCore -framework Security -framework StoreKit 
-framework SystemConfiguration -framework UIKit
PODS_CARDIO_OTHER_LDFLAGS = -lCardIO -lc++ -framework AVFoundation -framework AudioToolbox 
-framework CoreMedia -framework CoreVideo -framework MobileCoreServices -framework OpenGLES 
-framework QuartzCore -framework Security -framework UIKit
PODS_ROOT = ${SRCROOT}/Pods

[fabiopelosin]

@derpoliuk thanks for the investigation. The issue is related to the podspec of CardIO which is including a vendored library improperly. It should use the vendored_libraries DSL attribute.

To those interested I would suggest to contact the original author of the podspec or submit a pull request. A similar discussion can be found here: CocoaPods/Specs#5637.

---

@Zyphrax

@irrationalfab Would it be possible (with a small CocoaPods design change) to prevent changes to so many files when you add or remove a pod?

Yes, we plan to do it with the introduction of the headers quirks mode (#1626).

[yvbeek]

@irrationalfab Sounds great! Let me know if I can test something for you.

[derpoliuk]

@irrationalfab Thank you.

[fabiopelosin]

Closing this until further information that would confirm a bug is reported.