关于支付宝sdk和百度云推送sdk引入的base64.o编译报错问题

原先在项目中加入了百度云推送的sdk，看PDF集成的需要base64.h/base64.m的俩文件，之后一直没有没什么问题。直到要在项目中加入支付宝sdk的。按照说明集成配置完的。一编译直接包错了。

四处问了，确定应该是百度推送需要引入的base64.h/base64.m和支付宝sdk里面的AlipayRsaLib里面包含的base.o的一样的冲突。

开始还是想着.a的静态库的动不了那只有试着删除百度sdk引入的俩文件的，但是这俩文件一删除的。直接照成了百度推送的不能使用。。。

所以还是找其它方法的解决。开始也有人介绍如何合并.a的资料但是没接触过还是不敢弄。后来庆幸找到了一哥跟我一样的情况的。网址：点击打开链接，按照上面说的步奏一步步的试下来。开始的时候只移除了i386和armv7里面的base64.o保留了armv7s里面的。发现在模拟器上运行的真的可以编译通过了。但是真机运行还是会报上面的错误的。想想是不是armv7s没有移除的问题的。但是移除了全部的不知道对支付宝sdk的有没有影响的。所以还是和支付宝的客服询问了一下（支付宝客服还是很不错滴）。经过半天的了解。告诉了他们我的情况：在项目中已经加入了base64.h/base64.m的这俩文件的，那么将支付宝AlipayRsaLib.a里的base64.o的移除也是没有影响的。贴图：

所以，索性将armv7s里面的base64.o的一并移除了。再重新打了一个没有包含base64.o的库出来的。将它替换到测试的项目中运行的没有报错。用真机付款成功的也可以正常操作。试了百度推送的也是能正常运行的。

自己拷贝份保存下

[html]  view plain copy

1. （后面就不自己写了，直接copy过来稍加改动了）  
2.     开console，找到要解剖的.a文件，执行下列命令查看库包含的cpu架构代码：  
3. xcrun -sdk iphoneos lipo -info libx.a  
4. Architectures in the fat file: libx.a are: i386 armv7 armv7s  //此处如果直接使用lipo命令看到的会是： i386 armv7 （cputype（12）subcputyp（11））  
5.   
6. 然后用 xcrun -sdk iphoneos lipo -extract_family armv7 -output libx-inter.a libx.a  
7.   
8. 分离出arm版本的.a，这里有个小问题，按我的理解此命令应该对包含3种cpu代码的.a里的armv6部分进行操作，而实际分离出来的.a却是同时包含armv7和armv7s的部分，也就是依然是”fat” lib，这样是不能抽出.o的，因此还需要进行以下操作：  
9. lipo libx-inter.a -thin armv7 -output libx-armv7.a lipo libx-inter.a -thin armv7s -output libx-armv7s.a  
10. 这样就能分离出2份不同版本arm的.a了，然后进行解.o操作：  
11. ar -x libx-armv7.a  
12. 这部操作最好放到单独的文件夹里进行，会将link出.a的所有.o还原出来，然后有两种选择：一是把所有库对应cpu架构的部分都还原到这个位置，然后将重复的部分合并为一份，接着用后面的命令将所有.o再合并为一份公共lib。还有一种选择就是保留重复符号中的一份lib完好如初，将其余lib单独解开，剔出重复符号存在的.o，然后将该lib重新link回.a，以去除重复符号。  
13. 不管用哪种方法解决，最后的link回命令如下：  
14. libtool -static -o ../libx-armv7.a *.o  
15.   
16. 当然，别忘了咱们的库都是有多份cpu架构指令的，所以，先要对每种cpu arch的库进行同样操作，然后还要将thin lib合并回fat lib:  
17. lipo -create -output libx.a libx-armv7.a libx-i386.a libx-armv7s.a  
18. 这样，再link回自己的app时就不会再出现duplicate symbol了。   

贴出没有base64.o的AlipayRsaLib.a的地址：点击打开链接（支付宝版本v1.2，以后版本更新了如果修改了要重新按照原先的方法制作一份）

以上转载自：http://blog.csdn.net/sinyran/article/details/20708791

上边不懂的可以参考接下来的

iOS解决两个静态库的冲突 duplicate symbol  

解决TencentOpenAPI.framework与ZbarSDK中  _base64_encode 函数的冲突

后来在网络上搜寻，删除掉 Other Linker Flag 的 -all_load 就可以解决静态库冲突的问题，

但是这样做的话，会使一些外部的静态库，使用objc扩展函数(catagory)的方法失效。例如BaiduMapApi

如果是有些库使用到了扩展函数(catagory)可以分别对这个库进行加载

使用：-force_load

-force_load BaiduMapApi/libs/Release-iphoneos/libbaidumapapi.a

(BaiduMapApi是添加到当前目录下的)

或

-force_load $(BUILT_PRODUCTS_DIR)/libxxx.a

(这里是直接添加静态库项目源码的做法)

使用-force_load分别进行加载还是蛮方便的，如果有些函数加入了main函数使用all_load就相当麻烦了。

以上可以解决TencentOpenAPI.framework与ZbarSDK的冲突

如果两个静态库冲突的结构是相同的，可以考虑将两个静态库拆分出来进行合并。

在执行以下命令之前需要先获取xcode命令权限

$sudo xcode-select -switch /Applications/Xcode5.0.2.app/Contents/Developer

//这里边/Applications/Xcode5.0.2.app/Contents/Developer为xcode中developer路径

查看文件的架构有哪些
$ lipo -info libzbar.a
Architectures in the fat file: libzbar.a are: armv7 (cputype (12) cpusubtype (11)) i386 

将armv7解压出来

lipo libzbar.a -thin armv7 -output libzbar-armv7.a

新建立一个文件夹出来存放解压的(.o)文件
$ mkdir armv7
$ cd armv7

将静态库中的文件解压

$ ar -x ../libzbar-armv7.a


然后将另一个静态库根据以上的步骤做一遍，然后观察连个解压的静态库中，有那些是一样的就合并在一起，不过注意的是两个静态库冲突的(.o)文件必须一致，否则也会出现错误。

合并完后进行打包了
$ libtool -static -o ../libnew-armv7.a *.o


如果像在虚拟机也使用，进行相同的步骤后，将i386的架构合并再一起就可以了。

合并静态库
$ lipo -create -output lib.a libnew-armv76.a libi386.a