Cocoapods: Automatic creation of dummy classes causes conflict

[kballenegger]

A co-worker (@gonch) initially reported this in https://github.com/CocoaPods/Specs/issues/6915. I'm re-creating this here, since it was in the wrong repository.

There is no way to disable the automatic creation of the dummy objects (Pod-Podname-Dummy.m).

This is causing problems in our specific situation: we develop a library called Chartboost. Our library is developed with CocoaPods, and in our xcworkspace one of several targets is named Chartboost. This means that a dummy class named Pod-Chartboost-Dummy is created[1] because our Podfile specifies target 'Chartboost'.

We also ship our library as a pod itself, for others to use, as pod 'Chartboost'. This means that in our users' apps, a class named Pod-Chartboost-Dummy is also created, due to a coincidence in the way the dummy class' naming scheme is implemented.

This, as you can imagine, causes a linker error due to the duplicate symbol Pod-Chartboost-Dummy.

I see a couple potential solutions to the problem:

1. There could be a podspec flag that disables the automatic generation of this dummy class.
2. The dummy class name could be randomized, thus avoiding any naming conflicts. Maybe this is a lousy idea, though, because the result would then be non-deterministic.

[swizzlr]

So, our problem is that:

you have a target with the same name as one of the pods declared in your podfile?

[kballenegger]

I have a target in a project for our product (a static library), whose name is the same as the pod we maintain to let others use our static library.

I mean, the problem could be solved by re-naming the pod, or the target - but as you probably know, refactoring massive Xcode codebases can be a huge pain, and there really should be a better solution.

[CocoaPodsBot]

Issue has been confirmed by @segiddins

[segiddins]

The right way to handle this would probably be to emit an error if the install process generates a duplicate target name

[neonichu]

Just discussed this with @alloy and the reason for the dummy classes is making pods which package static libraries work. They should not be needed for pods which built from source. So the goal is to not create those classes at all in case they are superfluous.

I will assign this to me as I need it fixed for cocoapods-packager to not cause duplicated symbols.

[segiddins]

We really should handle this.

[AnthonyMDev]

Has this ever been fixed? I'm having this error come up right now, and am trying to find a workaround.

Thanks

[segiddins]

@AnthonyMDev as the issue is still open, it has not been fixed. If you would like to contribute a patch, that would be greatly appreciated.

[AnthonyMDev]

Didn't mean to sound pushy.
I would love to help, but I've got no experience with ruby and I'm not really sure what is going on here.

I have not be able to run my test targets on any of my static libraries built with Cocoapods since Xcode6 and I'm just wondering if this issue is still being addressed, or if it became stagnant.

Though, I don't really know how to fix this, if there is any information I can give you to help solve this, please let me know.

[segiddins]

@AnthonyMDev all that needs to be done is to not add the dummy class, which is done at https://github.com/CocoaPods/CocoaPods/blob/resolver-locking-dependencies/lib/cocoapods/installer/target_installer/pod_target_installer.rb#L19 and https://github.com/CocoaPods/CocoaPods/blob/resolver-locking-dependencies/lib/cocoapods/installer/target_installer/aggregate_target_installer.rb#L21, if the spec also includes any source files (.m files).

[AnthonyMDev]

Well, that doesn't seem like a difficult change to make at all. I have no ruby experience, but I can look at it and see if I can figure out what is going on.

[DikeyKing]

duplicate symbol _OBJC_METACLASS_$_PodsDummy_Pods in:
/Users/Dikey/Library/Developer/Xcode/DerivedData/BCRPrcessor-ewtrsnmnktgofuhgkomqziyehkrd/Build/Products/Release-iphoneos/libBCRPrcessor.a(Pods-dummy.o)
/Users/Dikey/Library/Developer/Xcode/DerivedData/CardDetect_iOSVersion-byomkbekirykcfgurowtzssvwtnn/Build/Products/Debug-iphoneos/libPods.a(Pods-dummy.o)
duplicate symbol _OBJC_CLASS_$_PodsDummy_Pods in:
/Users/Dikey/Library/Developer/Xcode/DerivedData/BCRPrcessor-ewtrsnmnktgofuhgkomqziyehkrd/Build/Products/Release-iphoneos/libBCRPrcessor.a(Pods-dummy.o)
/Users/Dikey/Library/Developer/Xcode/DerivedData/CardDetect_iOSVersion-byomkbekirykcfgurowtzssvwtnn/Build/Products/Debug-iphoneos/libPods.a(Pods-dummy.o)
ld: 2 duplicate symbols for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I meet the the same problems ,and I want to know how to avoid this when I am making a .a using cocoaPods.

[msncdma]

Don't use cocoapods when you're making the .a static library

[orta]

Don't use cocoapods when you're making the .a static library

You can use cocoapods-packager to fix this.

[msncdma]

thank you so much,

[phamquy]

I encounter this problems. Is it fixed?
This works for me as a work around: Delete the default generated target (when you create project), and create a new one with different name.

[DikeyKing]

I solved this problem at last by not using cocoa pods...I configure the framework by myself, I think this may be a good way.

[AnthonyMDev]

It’s pretty frustrating that the best solution we have to this problem is to no use CocoaPods at all…

On Dec 31, 2014, at 2:12 AM, Dikey [email protected] wrote:

I solved this problem at last by not using cocoa pods...I configure the framework by myself, I think this may be a good way.

—
Reply to this email directly or view it on GitHub https://github.com/CocoaPods/CocoaPods/issues/1767#issuecomment-68433644.

[kouky]

Have this issue too but with my iOS8 cocoa touch framework ...

[kouky]

This approach solved the issue for me http://stackoverflow.com/a/23370841/2360359

I'm building an iOS8 cocoa touch framework which uses the AFNetworking pod. The duplicate symbol warning showed up in a client app which used my custom framework and also included the AFNetworking pod as well.

[segiddins]

Can we at least start by getting rid of the dummy files when integrating as a framework, @mrackwitz ?

[segiddins]

@mrackwitz / @neonichu ping on that last question?

[neonichu]

@segiddins don't think so, at least for category-only Pods — but frameworks should avoid the original issue, though :)

[mrackwitz]

Yes, I think we can get rid of them with frameworks.

[segiddins]

Ok, let's test that and try and get that into 1.0 @mrackwitz

[WedgeSparda]

Any news about this?
I'm having the same issue and none of the answers I've found is helping me.

[AnthonyMDev]

Edited to remove marketing spam

[AnthonyMDev]

Edited (by @dantoml) to remove marketing spam

[orta]

@AnthonyMDev - we're still getting more spam BTW ^

[AnthonyMDev]

I'm so sorry. I thought I fixed that this morning. I'm going to try to lock down all my accounts. :/

[AnthonyMDev]

Edited (by @dantoml) to remove marketing spam

[dnkoutso]

One way to solve this is by adding EXCLUDED_SOURCE_FILE_NAMES=*-dummy.m in your podspec s.pod_target_xcconfig.

Until its fixed in CocoaPods land.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

[LJ8116]

s.pod_target_xcconfig = { 'EXCLUDED_SOURCE_FILE_NAMES' => '*-dummy.m'}

@dnkoutso solve my problem~ thx