Prevent duplicate symbols when building static library with Cocoapods

Question

While I've seen many questions dealing with Cocoapods and static libraries, most of them seem to assume you'll eventually have a single workspace with your static library and end target app.

In my scenario, I am building a static library. More specifically, I'm hacking a MyLib.framework for users to consume. I'd really like to manage MyLib.framework's dependencies with Cocoapods, but it creates many pain points when consumers of my library also use Cocoapods.

For example, my library has an AFNetworking dependency which I manage with Cocoapods. When I build my library, it links in libPods.a which includes AFNetworking, as well as some "dummy" files/objects. If users of my framework also use Cocoapods to build their app, they'll see something like this:

duplicate symbol _OBJC_METACLASS_$_PodsDummy_Pods in:
    /Users/erikkerber/Dropbox/Projects/MillMain/MyLib.framework/BuddySDK(Pods-dummy.o)
    /Users/erikkerber/Library/Developer/Xcode/DerivedData/MillMain-fngfqhlslygksgcfuciznkpqfrbr/Build/Products/Debug-iphonesimulator/libPods.a(Pods-dummy.o)
duplicate symbol _OBJC_CLASS_$_PodsDummy_Pods in:
    /Users/erikkerber/Dropbox/Projects/MillMain/MyLib.framework/BuddySDK(Pods-dummy.o)
    /Users/erikkerber/Library/Developer/Xcode/DerivedData/MillMain-fngfqhlslygksgcfuciznkpqfrbr/Build/Products/Debug-iphonesimulator/libPods.a(Pods-dummy.o)
ld: 2 duplicate symbols for architecture i386

I imagine if they were to add an AFNetworking dependency, that they would also get duplicate symbols relating to AFNetworking.

I plan to eventually distribute MyLib with Cocoapods as well, but I also want to be able to distribute a MyLib.framework itself.

Is there any way to use Cocoapods with my library while making Cocoapods safe to any potential user?

Answer 1

I had the same issue. I managed the dependencies of my library with cocoapods using the following podfile format:

platform :ios, '6.0'
pod 'AFNetworking'

This resulted in a Pods-dummy.o file in my .a file. If I then included this library in another project using the same podfile format, they both created a Pods-dummy.o symbol and results in a linker error. The solution is to use a different podfile format which results in a namespaced Pods-dummy symbol:

platform :ios, '6.0'
target "MyProject" do
    pod 'AFNetworking'
end

This results in a Pods-MyProject-dummy.o file, which won't cause duplicate symbols.

Note: if you switch your project over to using the new podfile format, make sure to unlink libPods.a from your project, since it will hang around as a broken link because the new pods library is named Pods-MyProject

Answer 2

In short, the only good way of distributing prebuilt libraries is by not including any of the dependencies, but leaving that up to the user. I.e. in your example, you would instruct your users how to also add AFNetworking to their project. The same basically applies regarding the dummy files.

Having said that, you could of course go for multiple prebuilt variants:

• Include all dependencies.
• Only include your lib’s source, leave dependencies up to the user.

We have been talking about creating a plugin to produce standalone static libraries, for the purpose that you want, but that’s as of yet not started and will probably take a little while longer. (Until someone/anyone has the time.)

As a workaround, you could use your Podfile’s post_install hook to remove the dummy files altogether. (these are only needed for non-source libs like Testflight anyways.) E.g. something like the following:

post_install do |installer|
  installer.project.targets.each do |target|
    source_files = target.source_build_phase.files
    dummy = source_files.find do |file|
      # TODO Fix this to the actual filename
      # puts "File: #{file.file_ref.name}"
      file.file_ref.name == 'TheDummyFile.m'
    end
    puts "Deleting source file #{dummy.inspect} from target #{target.inspect}."
    source_files.delete(dummy)
  end
end

This is untested code.

The post_install hook yields the CocoaPods installer object, from which you can get the Pods.xcodeproj targets, for which you can find documentation here. From there you can drill down and do anything you like to the project, which is saved to disk after running this hook.

Answer 3

If they are the same, you can merge them using:

libtool (libtool -o merged.a file1.a file2.a)

If this doesn't resolve the error, there is this option: http://atnan.com/blog/2012/01/12/avoiding-duplicate-symbol-errors-during-linking-by-removing-classes-from-static-libraries

Answer 4

With reference from http://guides.cocoapods.org/syntax/podfile.html#post_install & http://pdx.esri.com/blog/2013/12/13/namespacing-dependencies/

I use the 'Manually Rename All of the Symbols' approach. I was experiencing the duplicate symbol _OBJC_METACLASS_$_PodsDummy_Pods and so i added and edited the post_install in the Podfile to something like that to avoid the duplicate symbol

post_install do |installer_representation|
    installer_representation.pods_project.targets.each do |target|
        target.build_configurations.each do |config|
            config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = '$(inherited), PodsDummy_Pods=SomeOtherNamePodsDummy_Pods'
        end
    end
end