Objective-Zip，ZLib和MiniZip与Flurry 5.0.0的汇编失败并显示34 duplicate symbols for architecture i386。
报告的重复符号
_zipOpen , _unztell, _unzSetOffset, _unzClose等。
在Flurry 4.3.2上使用XCode 5.0时，同一项目编译正常
有谁遇到过这个问题？任何修复？
答案 0 :(得分：2)
我有这个问题，因为FlurryAds 5.0.0在内部使用ZipArchive，但我们也在自己的应用程序中使用ZipArchive（通过Cocoapods）。它可能是由Flurry使用的任何相同的zip相关库引起的。
如果您在应用程序的任何位置使用ZipArchive及其依赖项，则会出现冲突，因为您的ZipArchive和FlurryAds的ZipArchives副本都定义了相同的符号。
这是一个Objective-C问题，因为Objective-C不支持命名空间，它可以让两个副本共存。
你也可以责怪Flurry，因为他们正在分发二进制库而没有为其依赖项加前缀（即FlurryZipArchive，前缀可以替代命名空间。）
现在不完美的解决方案是从目标中移除ZipArchive.m，ioapi.c，mztools.c，unzip.c和zip.c。
你仍然可以导入ZipArchive.h并使用它，但它有点危险，因为我们不知道哪个版本的ZipArchive FlurryAds正在使用（或者他们可能已经修改过它），所以我们不能确保我们的头文件与它们在库中定义的符号兼容。
它可能很好，Flurry可能正在使用最新版本并且没有修改它。
但是，我们应该要求Flurry使ZipArchive成为一个明确的外部依赖项（因此我们可以共享一个安装和一个ZipArchive标头）或者为ZipArchive添加前缀，以便它不会影响其他依赖项。
答案 1 :(得分：1)
您需要添加另一个框架。新Flurry 5.0.0中还有一个需要添加的额外功能。它涉及以下框架：
libz.dylib
修改
尝试从构建过程中排除这些文件：ioapi.c / .h mztools.c / .h unzip.c / .h zip.c / .h ZipArchive.mm/.h crypt.h
祝你好运！答案 2 :(得分：0)
我遇到了同样的问题。
重命名unzip.h和unzip.m（For MiniZip） - 帮帮我。
答案 3 :(得分：0)
我在使用Flurry时遇到了同样的问题。我使用cocoapods并添加了ZipArchive和objective-zip个库作为依赖项。我的项目Other-Linker-Flags build settings的{{1}}中有一个超额价值：-all_load。
我的目标在$(inherited)中只有Other Linker Flags值，因此-all_load标志是从项目设置中隐式添加的。这就是那些链接器错误的原因