2

Objective-Zip, ZLib and MiniZip compilation with Flurry 5.0.0 fails with 34 duplicate symbols for architecture i386.

duplicate symbol reported for _zipOpen , _unztell, _unzSetOffset, _unzClose etc.

The same project compiles fine when Flurry 4.3.2 is used on XCode 5.0 Anyone faced this issue? Any fix?

danfelabs
  • 1,873
  • 1
  • 18
  • 23

4 Answers4

2

I had this problem because FlurryAds 5.0.0 uses ZipArchive internally, but we also use ZipArchive (via Cocoapods) in our own app. It could be caused by using any of the same zip-related libraries that Flurry uses.

If you are using ZipArchive and its dependencies anywhere in your app then there is a conflict because your copy of ZipArchive and FlurryAds's copy of ZipArchives are both defining the same symbols.

This is an Objective-C problem, because Objective-C doesn't support namespacing, which would let the two copies live together.

You can blame Flurry, also, because they are distributing a binary library without prefixing their dependencies (i.e. FlurryZipArchive, prefixing would be an alternative to namespacing).

The imperfect solution for now is to remove ZipArchive.m, ioapi.c, mztools.c, unzip.c, and zip.c from your target.

You can still import ZipArchive.h and use it, but it is somewhat dangerous because we don't know which version of ZipArchive FlurryAds is using (or if they might have modified it), so we can't be sure that our header file is compatible with the symbols they are defining in the library.

It's probably fine, Flurry probably is using the latest version and didn't modify it.

However, we should ask Flurry to either make ZipArchive an explicit external dependency (so we can share one installation and one header for ZipArchive) or to prefix ZipArchive so that it doesn't affect other dependencies.

divergio
  • 2,000
  • 13
  • 22
  • You can also remove the '-ObjC' from your linker flags to avoid the collision, but you no doubt put it in there with good reason. This SO answer covers the alternative to the -ObjC flag: http://stackoverflow.com/questions/11254269/using-the-force-load-linker-flag-with-restkit-ios. If Flurry could prefix the library, then implementation would be generally easier though. – Danny Parker Aug 01 '14 at 09:09
  • 1
    Flurry have confirmed the prefix didn't make it into 5.2, but should be in 5.3 so this problem should go away – Danny Parker Aug 13 '14 at 08:18
1

You need to add another Framework. There is one extra in the new Flurry 5.0.0 that you need to add. It is about the following Framework:

libz.dylib

EDIT:

Try excluding these files from the build process: ioapi.c/.h mztools.c/.h unzip.c/.h zip.c/.h ZipArchive.mm/.h crypt.h

Good luck!

Kets
  • 438
  • 2
  • 8
  • 24
  • 'libz.dylib' was already there. This is 'duplicate symbols' error. Your solution would apply to 'symbol not found' error. – danfelabs May 13 '14 at 21:23
  • @danfelabs added another solution from Flurry themselves. Gotten error to with the new SDK. – Kets May 14 '14 at 11:43
0

I had the same problem.

Rename unzip.h and unzip.m (For MiniZip) - helped for me.

user3645517
  • 1
0

I had a same issue without using Flurry. I was using cocoapods and added both ZipArchive and objective-zip libraries as dependencies. I had an excess value in my Other-Linker-Flags of my Project's build settings:-all_load.

My target had only $(inherited) value in its Other Linker Flags, so the -all_load flag was added implicitly from the project's settings. That was the reason for those linker errors

Tim
  • 1,877
  • 19
  • 27