请教库冲突的导致的 duplicate symbol 链接错误
3个回答
展开全部
场景:
解决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的冲突
如果两个静态库冲突的结构是相同的,可以考虑将两个静态库拆分出来进行合并。
查看文件的架构有哪些
$ 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
duplicate symbol是一种常见的链接错误,不像编译错误那样可以直接定位到问题的所在。但是经过一段时间的总结,发现这种错误总是有一些规律可以找的。
例如,我们有如下的最简单的两个类代码:
// ClassA.h
#import <Foundation/Foundation.h>
@interface ClassA : NSObject
@end
// ClassA.m
#import "ClassA.h"
@implementation ClassA
@end
// ClassB.h
#import <Foundation/Foundation.h>
@interface ClassB : NSObject
@end
// ClassB.m
#import "ClassB.h”
@implementation ClassB
@end
编译后出现的错误信息如下:
duplicate symbol _OBJC_METACLASS_$_ClassA in:
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassA.o
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassB.o
duplicate
symbol _OBJC_CLASS_$_ClassA in:
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassA.o
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassB.old:
2
duplicate symbols for architecture i386clang:
error: linker command failed with exit code 1 (use -v to see invocation)
从上面出现问题的地方,我们应该能推测出是ClassA这个类出了问题。如果这个类是我们自己写的,就容易办一些。
可以考虑以下原因:
1.引入头文件时,由于疏忽,误引入.m文件。这种一般仔细检查一下出现问题的类的源文件就能发现。
例:ClassB.m 文件修改成下面这样
#import "ClassB.h>"
#import "ClassA.m” // 这句话有问题
@implementation ClassB
@end
2.同一个类,实现两次,即有两个@implementation 。这种一般会有一个警告,也比较容易发现。
例:ClassB.m文件修改成下面这样:
// ClassB.m
#import "ClassB.h”
@implementation ClassB
@end
@implementation ClassA
@end
3.工程文件,同一个类文件被引入了两次,引起这种错误的原因大概有两种:一是多人协作开发时,导致project文件合并冲突;二是同名文件不在同一目录下,添加到工程时造成重复添加。 这种一般在文件视图,用名字过滤器检查一下就发现了。
4.
Targets的Build Phase设置项里,查看Complie
Sources这一项,看看出现问题的类是不是有重复的,用文件名过滤也比较容易发现。这种问题一般也是多人协作开发时,project文件冲突导致的。
发现这种问题,只要删除就可以了。不过在我解决问题过程中,删除其中一个文件时,重复文件会自动全部删除,所以还需要单独添加一下。
5.如果我们的工程中引用了第三方的库,而恰好第三方的库里面有一个ClassA,也会出现这种问题。如果不能修改第三方的库代码,只能修改我信自己的代码了。
解决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的冲突
如果两个静态库冲突的结构是相同的,可以考虑将两个静态库拆分出来进行合并。
查看文件的架构有哪些
$ 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
duplicate symbol是一种常见的链接错误,不像编译错误那样可以直接定位到问题的所在。但是经过一段时间的总结,发现这种错误总是有一些规律可以找的。
例如,我们有如下的最简单的两个类代码:
// ClassA.h
#import <Foundation/Foundation.h>
@interface ClassA : NSObject
@end
// ClassA.m
#import "ClassA.h"
@implementation ClassA
@end
// ClassB.h
#import <Foundation/Foundation.h>
@interface ClassB : NSObject
@end
// ClassB.m
#import "ClassB.h”
@implementation ClassB
@end
编译后出现的错误信息如下:
duplicate symbol _OBJC_METACLASS_$_ClassA in:
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassA.o
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassB.o
duplicate
symbol _OBJC_CLASS_$_ClassA in:
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassA.o
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassB.old:
2
duplicate symbols for architecture i386clang:
error: linker command failed with exit code 1 (use -v to see invocation)
从上面出现问题的地方,我们应该能推测出是ClassA这个类出了问题。如果这个类是我们自己写的,就容易办一些。
可以考虑以下原因:
1.引入头文件时,由于疏忽,误引入.m文件。这种一般仔细检查一下出现问题的类的源文件就能发现。
例:ClassB.m 文件修改成下面这样
#import "ClassB.h>"
#import "ClassA.m” // 这句话有问题
@implementation ClassB
@end
2.同一个类,实现两次,即有两个@implementation 。这种一般会有一个警告,也比较容易发现。
例:ClassB.m文件修改成下面这样:
// ClassB.m
#import "ClassB.h”
@implementation ClassB
@end
@implementation ClassA
@end
3.工程文件,同一个类文件被引入了两次,引起这种错误的原因大概有两种:一是多人协作开发时,导致project文件合并冲突;二是同名文件不在同一目录下,添加到工程时造成重复添加。 这种一般在文件视图,用名字过滤器检查一下就发现了。
4.
Targets的Build Phase设置项里,查看Complie
Sources这一项,看看出现问题的类是不是有重复的,用文件名过滤也比较容易发现。这种问题一般也是多人协作开发时,project文件冲突导致的。
发现这种问题,只要删除就可以了。不过在我解决问题过程中,删除其中一个文件时,重复文件会自动全部删除,所以还需要单独添加一下。
5.如果我们的工程中引用了第三方的库,而恰好第三方的库里面有一个ClassA,也会出现这种问题。如果不能修改第三方的库代码,只能修改我信自己的代码了。
推荐于2018-03-08 · 知道合伙人数码行家
huanglenzhi
知道合伙人数码行家
向TA提问 私信TA
知道合伙人数码行家
采纳数:117538
获赞数:517195
长期从事计算机组装,维护,网络组建及管理。对计算机硬件、操作系统安装、典型网络设备具有详细认知。
向TA提问 私信TA
关注
展开全部
自己解决了,就贴下解决办法方便后来人吧.
查看了JCNotificationBannerPresenterIOSStyle源代码,
发现有冲突的是以下可能是由以下两个函数名,可能编译后编译器将名字加了_前缀.
CGFloat DegreesToRadians(CGFloat degrees) { return degrees * M_PI / 180.0; };
CGFloat RadiansToDegrees(CGFloat radians) { return radians * 180.0 / M_PI; };
可能是作为两个简单的函数,跟其他的函数冲突了吧.
我的做法时,不在使用cocoapods管理此库,而是下载下来做为项目的一部分,
然后修改源代码:
将上面的函数名更改一下:
CGFloat MyDegreesToRadians(CGFloat degrees) { return degrees * M_PI / 180.0; };
CGFloat MyRadiansToDegrees(CGFloat radians) { return radians * 180.0 / M_PI; };
然后编译就通过了!~
查看了JCNotificationBannerPresenterIOSStyle源代码,
发现有冲突的是以下可能是由以下两个函数名,可能编译后编译器将名字加了_前缀.
CGFloat DegreesToRadians(CGFloat degrees) { return degrees * M_PI / 180.0; };
CGFloat RadiansToDegrees(CGFloat radians) { return radians * 180.0 / M_PI; };
可能是作为两个简单的函数,跟其他的函数冲突了吧.
我的做法时,不在使用cocoapods管理此库,而是下载下来做为项目的一部分,
然后修改源代码:
将上面的函数名更改一下:
CGFloat MyDegreesToRadians(CGFloat degrees) { return degrees * M_PI / 180.0; };
CGFloat MyRadiansToDegrees(CGFloat radians) { return radians * 180.0 / M_PI; };
然后编译就通过了!~
本回答被提问者和网友采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
场景:
解决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的冲突
如果两个静态库冲突的结构是相同的,可以考虑将两个静态库拆分出来进行合并。
查看文件的架构有哪些
$ 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
duplicate symbol是一种常见的链接错误,不像编译错误那样可以直接定位到问题的所在。但是经过一段时间的总结,发现这种错误总是有一些规律可以找的。
例如,有如下的最简单的两个类代码:
// ClassA.h
#import <Foundation/Foundation.h>
@interface ClassA : NSObject
@end
// ClassA.m
#import "ClassA.h"
@implementation ClassA
@end
// ClassB.h
#import <Foundation/Foundation.h>
@interface ClassB : NSObject
@end
// ClassB.m
#import "ClassB.h”
@implementation ClassB
@end
编译后出现的错误信息如下:
duplicate symbol _OBJC_METACLASS_$_ClassA in:
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassA.o
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassB.o
duplicate symbol _OBJC_CLASS_$_ClassA in: /Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassA.o
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassB.old: 2
duplicate symbols for architecture i386clang:
error: linker command failed with exit code 1 (use -v to see invocation)
从上面出现问题的地方,应该能推测出是ClassA这个类出了问题。如果这个类是自己写的,就容易办一些。
可以考虑以下原因:
1.引入头文件时,由于疏忽,误引入.m文件。这种一般仔细检查一下出现问题的类的源文件就能发现。
例:ClassB.m 文件修改成下面这样
#import "ClassB.h>"
#import "ClassA.m” // 这句话有问题
@implementation ClassB
@end
2.同一个类,实现两次,即有两个@implementation 。这种一般会有一个警告,也比较容易发现。
例:ClassB.m文件修改成下面这样:
// ClassB.m
#import "ClassB.h”
@implementation ClassB
@end
@implementation ClassA
@end
3.工程文件,同一个类文件被引入了两次,引起这种错误的原因大概有两种:一是多人协作开发时,导致project文件合并冲突;二是同名文件不在同一目录下,添加到工程时造成重复添加。 这种一般在文件视图,用名字过滤器检查一下就发现了。
4. Targets的Build Phase设置项里,查看Complie Sources这一项,看看出现问题的类是不是有重复的,用文件名过滤也比较容易发现。这种问题一般也是多人协作开发时,project文件冲突导致的。发现这种问题,只要删除就可以了。不过在解决问题过程中,删除其中一个文件时,重复文件会自动全部删除,所以还需要单独添加一下。
5.如果工程中引用了第三方的库,而恰好第三方的库里面有一个ClassA,也会出现这种问题。如果不能修改第三方的库代码,只能修改我信自己的代码了。
解决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的冲突
如果两个静态库冲突的结构是相同的,可以考虑将两个静态库拆分出来进行合并。
查看文件的架构有哪些
$ 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
duplicate symbol是一种常见的链接错误,不像编译错误那样可以直接定位到问题的所在。但是经过一段时间的总结,发现这种错误总是有一些规律可以找的。
例如,有如下的最简单的两个类代码:
// ClassA.h
#import <Foundation/Foundation.h>
@interface ClassA : NSObject
@end
// ClassA.m
#import "ClassA.h"
@implementation ClassA
@end
// ClassB.h
#import <Foundation/Foundation.h>
@interface ClassB : NSObject
@end
// ClassB.m
#import "ClassB.h”
@implementation ClassB
@end
编译后出现的错误信息如下:
duplicate symbol _OBJC_METACLASS_$_ClassA in:
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassA.o
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassB.o
duplicate symbol _OBJC_CLASS_$_ClassA in: /Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassA.o
/Users/dajie/Library/Developer/Xcode/DerivedData/linkTest-cpjaaatiyqpvxcbzfzpklcbqrgqg/Build/Intermediates/linkTest.build/Debug-iphonesimulator/linkTest.build/Objects-normal/i386/ClassB.old: 2
duplicate symbols for architecture i386clang:
error: linker command failed with exit code 1 (use -v to see invocation)
从上面出现问题的地方,应该能推测出是ClassA这个类出了问题。如果这个类是自己写的,就容易办一些。
可以考虑以下原因:
1.引入头文件时,由于疏忽,误引入.m文件。这种一般仔细检查一下出现问题的类的源文件就能发现。
例:ClassB.m 文件修改成下面这样
#import "ClassB.h>"
#import "ClassA.m” // 这句话有问题
@implementation ClassB
@end
2.同一个类,实现两次,即有两个@implementation 。这种一般会有一个警告,也比较容易发现。
例:ClassB.m文件修改成下面这样:
// ClassB.m
#import "ClassB.h”
@implementation ClassB
@end
@implementation ClassA
@end
3.工程文件,同一个类文件被引入了两次,引起这种错误的原因大概有两种:一是多人协作开发时,导致project文件合并冲突;二是同名文件不在同一目录下,添加到工程时造成重复添加。 这种一般在文件视图,用名字过滤器检查一下就发现了。
4. Targets的Build Phase设置项里,查看Complie Sources这一项,看看出现问题的类是不是有重复的,用文件名过滤也比较容易发现。这种问题一般也是多人协作开发时,project文件冲突导致的。发现这种问题,只要删除就可以了。不过在解决问题过程中,删除其中一个文件时,重复文件会自动全部删除,所以还需要单独添加一下。
5.如果工程中引用了第三方的库,而恰好第三方的库里面有一个ClassA,也会出现这种问题。如果不能修改第三方的库代码,只能修改我信自己的代码了。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询