Cocoapods: Cannot add new pods to project : Undefined symbols for architecture i386

Created on 11 Mar 2013 · 31Comments · Source: CocoaPods/CocoaPods

Hey everyone, I've been pulling my hair for more than a week on this issue now and I can't seem to find anything at all.
I don"t know why or how, but at one point my project stopped accepting more Pods, let me explain. Here is my Podfile :

`platform :ios, '4.3'
pod 'SVGeocoder', :git => 'https://github.com/kirualex/SVGeocoder.git'
pod 'KALayoutHelper', :git => 'https://github.com/kirualex/KALayoutHelper.git'
pod 'SBJson', '3.1.1'
pod 'AFNetworking', '0.10.1'
pod 'SDWebImage', '2.4'
pod 'SVProgressHUD'
pod 'iActiveRecord'``

Everything is working great with it, but here's the trick, as soon as I want to add a new pod (such as Flurry or Crittercism), I get the same kind of error :

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

I'm getting very frustrated with this as I'm near the end of this project and I am currently forced to import these libraries by the "dirty old way" ! Any help would be very very much appreciated !

Thanks guys !

Source

kirualex

Most helpful comment

I don’t know about all the pods you’re already using, but at least the flurry and crittercism ones are shipped as static libraries and so probably that’s the difference.

When Xcode ‘mysteriously’ fails to build, _always_ first try:

$ rm -rf DerivedData
Restart Xcode.app

alloy on 11 Mar 2013

👍10 🎉6

All 31 comments

Ambulance to the rescue!!

What is your version of CocoaPods
Does your Pods project compile (it looks like so)
Does it include the Crittercism files in the files navigator?
Does it include the files in the Compile source files build phase of your target?
Does deleting the Pods folder fix your issue?

fabiopelosin on 11 Mar 2013

I don’t know about all the pods you’re already using, but at least the flurry and crittercism ones are shipped as static libraries and so probably that’s the difference.

When Xcode ‘mysteriously’ fails to build, _always_ first try:

$ rm -rf DerivedData
Restart Xcode.app

alloy on 11 Mar 2013

👍10 🎉6

@irrationalfab

Cocoapods gem version 1.8.24
My Pods project does compile fine
Crittercism files are visible in the navigator (both from xCode and finder)
There are no file from Crittercism in 'compile source' file build phase (Headers are fine though) <- Maybe an issue here ?
Deleting Pods folder and Podfile.lock does not fix the issue

kirualex on 11 Mar 2013

Also I tried deleting the DerivedData as well as multiple cleans (the full cmd-alt-shift-k one) but no luck either...
Thanks for your recommendations though. The funny thing is that another project using FlurrySDK and Crittercism is building without any issue, with only the os version different (5.1 instead of 4.3 here).

kirualex on 11 Mar 2013

Cocoapods gem version 1.8.24

That is the RubyGems version for the CocoaPods you can run:

$ pod --version

Regarding CrittercismSDK the CrittercismSDK/libCrittercism_v3_4_9.a file should be present in the folder of the Pod. Other than that the only issues that I can are:

Your target is not using the Pods.xcconfig (you can also check that the -lCrittercism_v3_4_9 flag is there)
You are overriding the LIBRARY_SEARCH_PATHS build settings without using $(inherited).

fabiopelosin on 11 Mar 2013

my bad, pod version is 0.16.4.
CrittercismSDK/libCrittercism_v3_4_9.a is present in the folder when accessed via the finder.

here is my Pods.xconfig looking not bad :

ALWAYS_SEARCH_USER_PATHS = YES GCC_PREPROCESSOR_DEFINITIONS = $(inherited) SQLITE_CORE SQLITE_ENABLE_UNICODE HEADER_SEARCH_PATHS = ${PODS_HEADERS_SEARCH_PATHS} LIBRARY_SEARCH_PATHS = "$(PODS_ROOT)/CrittercismSDK/CrittercismSDK" OTHER_LDFLAGS = -ObjC -lCrittercism_v3_4_9 -lsqlite3 -framework CoreLocation, MapKit -framework Foundation -framework QuartzCore -framework SystemConfiguration PODS_BUILD_HEADERS_SEARCH_PATHS = "${PODS_ROOT}/BuildHeaders" "${PODS_ROOT}/BuildHeaders/AFNetworking" "${PODS_ROOT}/BuildHeaders/CrittercismSDK" "${PODS_ROOT}/BuildHeaders/KALayoutHelper" "${PODS_ROOT}/BuildHeaders/SBJson" "${PODS_ROOT}/BuildHeaders/SDWebImage" "${PODS_ROOT}/BuildHeaders/SVGeocoder" "${PODS_ROOT}/BuildHeaders/SVProgressHUD" "${PODS_ROOT}/BuildHeaders/iActiveRecord" PODS_HEADERS_SEARCH_PATHS = ${PODS_PUBLIC_HEADERS_SEARCH_PATHS} PODS_PUBLIC_HEADERS_SEARCH_PATHS = "${PODS_ROOT}/Headers" "${PODS_ROOT}/Headers/AFNetworking" "${PODS_ROOT}/Headers/CrittercismSDK" "${PODS_ROOT}/Headers/KALayoutHelper" "${PODS_ROOT}/Headers/SBJson" "${PODS_ROOT}/Headers/SDWebImage" "${PODS_ROOT}/Headers/SVGeocoder" "${PODS_ROOT}/Headers/SVProgressHUD" "${PODS_ROOT}/Headers/iActiveRecord" PODS_ROOT = ${SRCROOT}/Pods

I'm having a look for any override and I'll come back to you on that point.

kirualex on 11 Mar 2013

I don't see any override on header search path or library search path...
Headers
${PODS_HEADERS_SEARCH_PATHS}
$(inherited)
Libraries
$(SRCROOT)
$(inherited)

All on non-recursive

kirualex on 11 Mar 2013

To be clear you should be checking this in your target of your app. If everything looks good the only hint that I have left is that the file Pods/CrittercismSDK/libCrittercism_v3_4_9.a is missing.

fabiopelosin on 11 Mar 2013

Ok so could you explain a little more how to check that the file is in my target and how to add it in case it isn't?

kirualex on 11 Mar 2013

You xcconfig looks good to me and your target should be correctly configured to use it otherwise you would not be able to use headers of the Pods.

Screen Shot 2013-03-11 at 17 35 34

Regarding the Pods/CrittercismSDK/libCrittercism_v3_4_9.a I just meant to check that it exits although I think so because you deleted the Pods folders. I this stuff is correctly set up I have no clue why Xcode is not picking up the lib.

fabiopelosin on 11 Mar 2013

Alright, seems like everything is set up properly, but the issue still remains. A big thanks for your time, I'll keep looking and update this thread in case I make any discovery.

kirualex on 11 Mar 2013

Ok so could you explain a little more how to check that the file is in my target and how to add it in case it isn't?

Ensure that the values (not just the keys) that are defined in the Pods.xcconfig file show up exactly the same in the build setting of _your_ target in _your_ project.

This wiki page outlines the steps you should take to integrate CocoaPods manually.

alloy on 11 Mar 2013

OK I'll have a look. For now one thing is sure : only static libraries are problematic. I tried with non-static ones and it compile successfully.

kirualex on 12 Mar 2013

So I found an issue that put me on the way : https://github.com/CocoaPods/CocoaPods/issues/225

For now the only way to resolve this is to drag and drop the static library (here libCrittercism_v3_4_9.a) from the finder to the link Binary with Libraries section under the Build Phases of your Pods project.

kirualex on 12 Mar 2013

That ticket is unrelated. It‘s about the case where there no source files in your dependencies at all, but you do have those and we also fixed that issue by adding a dummy source file.

If you can share your project I’d be willing to take a quick look.

alloy on 12 Mar 2013

Unfortunately I cannot share this project source (not my property). The dummy file source is here btw, so I have no definitive answer apart from the temporary solution I put a little earlier.
I would be interested in any other ideas you may have though !

kirualex on 12 Mar 2013

Xcode and its build settings is unfortunately too big of a scope to go through all the details in this manner.

One thing you can do is create a new project and add these libs with CocoaPods to it and verify they actually work in isolation. Then, if it works, you can try to find the failure reason by comparing the build settings of the two.

alloy on 12 Mar 2013

This is a good task for Xcodeproj which should be fairly updated with your version of CocoaPods:

$ xcodeproj show NAME.xcodeproj

Note that this will not print the values inherited by the xcconfig but you already confirmed that the Pods.xcconfig it is working on another project.

I didn't think about it but sharing the last section of the output of that command (the Build Configurations of the Project and of the target) could help us understand the issue as well.

fabiopelosin on 12 Mar 2013

OK I took what seem to be the more useful stuff from the output :

File References

- Classes:
  ...
- Resources:
  ...
- Supporting Files:
  - project-Info.plist
  - main.m
  - project-Prefix.pch

- Frameworks:
  - MapKit.framework
  - SystemConfiguration.framework
  - CoreLocation.framework
  - QuartzCore.framework
  - UIKit.framework
  - Foundation.framework
  - CoreGraphics.framework
  - libPods.a

- Products:
  - project.app

- Pods.xcconfig

Targets
- project:
    Build Phases:
    - SourcesBuildPhase:
     ...

    - FrameworksBuildPhase:
      - MapKit.framework
      - SystemConfiguration.framework
      - CoreLocation.framework
      - QuartzCore.framework
      - UIKit.framework
      - Foundation.framework
      - CoreGraphics.framework
      - libPods.a
    - ResourcesBuildPhase:
      ...

    - Copy Pods Resources: []
    Build Configurations:
    - Debug:
        Build Settings:
          GCC_PREFIX_HEADER: project/project-Prefix.pch
          PRODUCT_NAME: $(TARGET_NAME)
          INFOPLIST_FILE: project/project-Info.plist
          CODE_SIGN_IDENTITY: ...
          WRAPPER_EXTENSION: app
          PROVISIONING_PROFILE[sdk=iphoneos*]: ...
          HEADER_SEARCH_PATHS:
          - ${PODS_HEADERS_SEARCH_PATHS}
          - $(inherited)
          CODE_SIGN_IDENTITY[sdk=iphoneos*]: ! 'iPhone Developer: ...'
          GCC_PRECOMPILE_PREFIX_HEADER: 'YES'
          OTHER_LDFLAGS:
          - -ObjC
          - -lsqlite3
          - -framework
          - QuartzCore
          - -framework
          - SystemConfiguration
          LIBRARY_SEARCH_PATHS:
          - $(SRCROOT)
          - $(inherited)
          - ! '"$(SRCROOT)/Pods/CrittercismSDK/CrittercismSDK"'
          - ! '"$(SRCROOT)/Pods/FlurrySDK/Flurry"'
          COPY_PHASE_STRIP: 'YES'
          PROVISIONING_PROFILE: ...
        Base Configuration: Pods.xcconfig
    - Release:
        Build Settings:
          GCC_PREFIX_HEADER: project/project-Prefix.pch
          INFOPLIST_FILE: project/project-Info.plist
          CODE_SIGN_IDENTITY: iPhone Distribution
          WRAPPER_EXTENSION: app
          PROVISIONING_PROFILE[sdk=iphoneos*]: ''
          HEADER_SEARCH_PATHS:
          - ${PODS_HEADERS_SEARCH_PATHS}
          - $(inherited)
          CODE_SIGN_IDENTITY[sdk=iphoneos*]: iPhone Distribution
          GCC_PRECOMPILE_PREFIX_HEADER: 'YES'
          OTHER_LDFLAGS:
          - -ObjC
          - -lsqlite3
          - -framework
          - QuartzCore
          - -framework
          - SystemConfiguration
          LIBRARY_SEARCH_PATHS:
          - $(SRCROOT)
          - $(inherited)
          - ! '"$(SRCROOT)/Pods/CrittercismSDK/CrittercismSDK"'
          - ! '"$(SRCROOT)/Pods/FlurrySDK/Flurry"'
          PRODUCT_NAME: $(TARGET_NAME)
          PROVISIONING_PROFILE: ''
        Base Configuration: Pods.xcconfig

Build Configurations
- Debug:
    Build Settings:
      PROVISIONING_PROFILE: ...
      GCC_WARN_ABOUT_RETURN_TYPE: 'YES'
      GCC_PREPROCESSOR_DEFINITIONS:
      - DEBUG=1
      - $(inherited)
      ONLY_ACTIVE_ARCH: 'NO'
      GCC_SYMBOLS_PRIVATE_EXTERN: 'NO'
      GCC_WARN_UNINITIALIZED_AUTOS: 'YES'
      CLANG_CXX_LANGUAGE_STANDARD: gnu++0x
      GCC_OPTIMIZATION_LEVEL: '0'
      GCC_C_LANGUAGE_STANDARD: gnu99
      LIBRARY_SEARCH_PATHS: $(inherited)
      CLANG_WARN__DUPLICATE_METHOD_MATCH: 'YES'
      CLANG_WARN_EMPTY_BODY: 'YES'
      OTHER_LDFLAGS: $(inherited)
      ALWAYS_SEARCH_USER_PATHS: 'NO'
      COPY_PHASE_STRIP: 'NO'
      CLANG_ENABLE_OBJC_ARC: 'YES'
      HEADER_SEARCH_PATHS:
      - $(inherited)
      - $(BUILT_PRODUCTS_DIR)
      - ${PODS_HEADERS_SEARCH_PATHS}
      PROVISIONING_PROFILE[sdk=iphoneos*]: ...
      SDKROOT: iphoneos
      IPHONEOS_DEPLOYMENT_TARGET: '4.3'
      CODE_SIGN_IDENTITY: ! 'iPhone Developer: ...'
      GCC_DYNAMIC_NO_PIC: 'NO'
      CODE_SIGN_IDENTITY[sdk=iphoneos*]: ! 'iPhone Developer: ...'
      CLANG_CXX_LIBRARY: libc++
      GCC_WARN_UNUSED_VARIABLE: 'YES'

- Release:
    Build Settings:
      VALIDATE_PRODUCT: 'YES'
      PROVISIONING_PROFILE: ''
      GCC_WARN_ABOUT_RETURN_TYPE: 'YES'
      ONLY_ACTIVE_ARCH: 'NO'
      GCC_WARN_UNINITIALIZED_AUTOS: 'YES'
      CLANG_CXX_LANGUAGE_STANDARD: gnu++0x
      LIBRARY_SEARCH_PATHS: $(inherited)
      GCC_C_LANGUAGE_STANDARD: gnu99
      CLANG_WARN__DUPLICATE_METHOD_MATCH: 'YES'
      OTHER_CFLAGS: -DNS_BLOCK_ASSERTIONS=1
      CLANG_WARN_EMPTY_BODY: 'YES'
      OTHER_LDFLAGS: ''
      ALWAYS_SEARCH_USER_PATHS: 'NO'
      COPY_PHASE_STRIP: 'YES'
      CLANG_ENABLE_OBJC_ARC: 'YES'
      HEADER_SEARCH_PATHS:
      - $(inherited)
      - $(BUILT_PRODUCTS_DIR)
      - ${PODS_HEADERS_SEARCH_PATHS}
      PROVISIONING_PROFILE[sdk=iphoneos*]: ''
      SDKROOT: iphoneos
      CODE_SIGN_IDENTITY[sdk=iphoneos*]: iPhone Distribution
      CODE_SIGN_IDENTITY: iPhone Distribution
      IPHONEOS_DEPLOYMENT_TARGET: '4.3'
      CLANG_CXX_LIBRARY: libc++
      GCC_WARN_UNUSED_VARIABLE: 'YES'

kirualex on 12 Mar 2013

The OTHER_LDFLAGS of the target are set and don't specify ($inherited). I thought that we had that ruled out but I'm noticing that I was not explicit about this key.

fabiopelosin on 12 Mar 2013

OK we have some changes when adding $(inherited) to the OTHER_LD_FLAGS, I now have a linker error :
clang: error: no such file or directory: 'MapKit' .
I cleaned and reinstalled the Pods but no luck.

kirualex on 12 Mar 2013

OK I managed to get the project compiling by removing MapKit -framework Foundation -framework QuartzCore -framework SystemConfiguration from OTHER_LD_FLAGS in my Pods.xconfig file.
I now have :
OTHER_LDFLAGS = -ObjC -lCrittercism_v3_4_9 -lFlurry -lsqlite3 -framework CoreLocation

Not sure why it was causing the issue.

kirualex on 12 Mar 2013

Your podspec for SVGeocoder is broken. This line should be an array:

s.framework = 'CoreLocation', 'MapKit'

fabiopelosin on 12 Mar 2013

Thanks, I'm not in front o my computer right now but it look like the proper solution ! Thanks so much@irrationalFab !

kirualex on 12 Mar 2013

So just for the follow up, I updated the SVGeocoder podspec and everything is back on track. Thanks again guys !

kirualex on 13 Mar 2013

:beers:

fabiopelosin on 13 Mar 2013

did you get warning when use "pod install" or "pod search" ,The target zhiyoula [Debug] overrides the OTHER_LDFLAGS build setting defined in `Pods/Pods-zhiyoula.xcconfig'

Futurecompiler on 7 May 2014

i solve the problem by remove all the "other linker flags" objects!
my cocoapods version is "0.32.1"
(that cost my whole night ,wish can help you guys)

Futurecompiler on 7 May 2014

Hmm try this :

Go to your Pods project inside your workspace, deep clean, and then install this gist and finally Build. Afterwards go to Debug-Universal (newly created dir where xCode stores its Products), and copy paste the new .a file (which will be a fat one - both armv7 for ios and i386 for ios simulator) on your main project - in the same workspace. I did this and no longer get undefined symbols for i386.