Caleb
Caleb

Reputation: 125037

How do I solve linker errors from the Cocoapods lint command?

I have a library written for iOS in Objective-C that we publish via Cocoapods, and recently I've been getting a pair of link errors when I try to validate the pod with the pod lib lint command. Both errors look like this (with names changed to protect the innocent):

Ld /Users/myusername/Library/Developer/Xcode/DerivedData/App-akupndrkecikjfdfvjfyniytivhf/Build/Intermediates.noindex/App.build/Release-iphonesimulator/App.build/Objects-normal/x86_64/Binary/App normal x86_64 (in target 'App' from project 'App')
    cd /var/folders/4v/jcw9j9x126j5wsmpqmhhswx40000gn/T/CocoaPods-Lint-20191211-37020-sasgf-FooBarSDK
    /Applications/Xcode-11.2.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -target x86_64-apple-ios8.0-simulator -isysroot /Applications/Xcode-11.2.1.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator13.2.sdk -L/Users/myusername/Library/Developer/Xcode/DerivedData/App-akupndrkecikjfdfvjfyniytivhf/Build/Products/Release-iphonesimulator -L/Users/myusername/Library/Developer/Xcode/DerivedData/App-akupndrkecikjfdfvjfyniytivhf/Build/Products/Release-iphonesimulator/FooBarSDK -L/Users/myusername/Library/Developer/Xcode/DerivedData/App-akupndrkecikjfdfvjfyniytivhf/Build/Products/Release-iphonesimulator/TFooBarSDK -L/var/folders/4v/jcw9j9x126j5wsmpqmhhswx40000gn/T/CocoaPods-Lint-20191211-37020-sasgf-FooBarSDK/Pods/TFooBarSDK/FooBar -F/Users/myusername/Library/Developer/Xcode/DerivedData/App-akupndrkecikjfdfvjfyniytivhf/Build/Products/Release-iphonesimulator -filelist /Users/myusername/Library/Developer/Xcode/DerivedData/App-akupndrkecikjfdfvjfyniytivhf/Build/Intermediates.noindex/App.build/Release-iphonesimulator/App.build/Objects-normal/x86_64/App.LinkFileList -Xlinker -rpath -Xlinker @executable_path/Frameworks -dead_strip -Xlinker -object_path_lto -Xlinker /Users/myusername/Library/Developer/Xcode/DerivedData/App-akupndrkecikjfdfvjfyniytivhf/Build/Intermediates.noindex/App.build/Release-iphonesimulator/App.build/Objects-normal/x86_64/App_lto.o -Xlinker -objc_abi_version -Xlinker 2 -fobjc-arc -fobjc-link-runtime -ObjC -lFooBar_1.2.4 -lFooBarSDK -lTFooBarSDK -lz -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __entitlements -Xlinker /Users/myusername/Library/Developer/Xcode/DerivedData/App-akupndrkecikjfdfvjfyniytivhf/Build/Intermediates.noindex/App.build/Release-iphonesimulator/App.build/App.app-Simulated.xcent -framework Foundation -lPods-App -Xlinker -dependency_info -Xlinker /Users/myusername/Library/Developer/Xcode/DerivedData/App-akupndrkecikjfdfvjfyniytivhf/Build/Intermediates.noindex/App.build/Release-iphonesimulator/App.build/Objects-normal/x86_64/App_dependency_info.dat -o /Users/myusername/Library/Developer/Xcode/DerivedData/App-akupndrkecikjfdfvjfyniytivhf/Build/Intermediates.noindex/App.build/Release-iphonesimulator/App.build/Objects-normal/x86_64/Binary/App
Undefined symbols for architecture x86_64:
  "_OBJC_CLASS_$_FooBar", referenced from:
      l_OBJC_$_CATEGORY_FooBar_$_ForceLoad in libFooBarSDK.a(FooBarEmpty.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The problem may have started when I moved the project up to Xcode 10.3 or 11.2 (happens the same with both versions) from Xcode 9.x, or that might be a red herring.

My understanding is that, among other sanity checks, pod lib lint creates an application project that includes the library in question (libFooBarSDK in this case) and tries to build it, and it looks like that project's linking phase is what generates this error. However, our test application links against the library with no problems.

pod --version says I'm using version 1.7.5 of Cocoapods, by the way.

My questions:

Upvotes: 0

Views: 332

Answers (3)

Raman
Raman

Reputation: 19685

Use CocoaPods spec.libraries to add your library as a dependency. CocoaPods should then link it during linting. For example:

    spec.libraries = 'c++', 'sqlite3'

Alternatively you can add a -l argument directly to compiler_flags.

Upvotes: 1

Paul Beusterien
Paul Beusterien

Reputation: 29602

Add the option --verbose to get a more detailed log about the failure. Add the option --no-clean to save the Xcode workspace from which you can debug the linker symbol problem.

Upvotes: 1

Arik Segal
Arik Segal

Reputation: 3031

I'm no expert in Pods, but if this check does create a demo project like you wrote, maybe it has a build phase for removing simulator architecture (in order to avoid AppStore rejection).

This script is usually a variation of this one: http://ikennd.ac/blog/2015/02/stripping-unwanted-architectures-from-dynamic-libraries-in-xcode/

If the project build runs such a script, the build might fail when the target is a simulator and not a real device.

Upvotes: 0

Related Questions