文章转自(https://blog.csdn.net/bobo553443/article/details/78633340)

linker command failed with exit code 1！错误总结

我只是一名勤劳的搬运工，方便大家解决问题。

很多新手iOS开发者，总会面对各种各样奇葩的运行错误，但当你工作了一段时间后，就会发现linker系列会一直缠绕这你，马上2016年了，我也总结一下常见的linker系列BUG。

1.最近遇到一个关于CocoPods的linker错误，就是当你网上去下载一些之前的完整的项目的时候，用终端也 pod update了，但一运行，熟悉的linker错误就出来了。解决办法是：1.再Other Linker Flags（也即 OTHER_LDFLAGS）中添加(PODS_ROOT)/Headers。

2.当有的时候你从网上下载第三方类库拉到项目里编译的时候linker兄弟就会又来找你了，有的新手开发者就会以为是类库或者自己项目的原因，其实不是的，解决方法如下：在Target-->Build Phases-->compile Sources 中，第三方库的所有.m文件都添加到里面，然后就可以了。

3.还有个常见的情况，xcode7.0以后，模拟器运行没事，可是真机运行就会出错。解决办法：选中项目->双击->target->buildSeting->搜索BITCODE,默认是yes，修改成no。 重新编译就OK了。

4.当多人开发的时候，也会出现这样的错误，多是由于哪个文件重复引用或者类名引用多次导致的，细心点就能查出来。

新手开发者遇到BUG不要急，细心点就会找到BUG的源泉，最后祝大家BUG少少，幸福美好。

使用场景

在ios开发中，我们经常会使用到第三方的一些静态库,导入第三方类库运行程序后你会发现,编译时可以正常编译但是运行时会app会闪退,报出selector not recognized的错误。一般的第三方库的开发文档中都会写出这种问题的解决方法,如在Other Linker Flags中加入-ObjC或者-all_load或者-force_load这样的解决方法。为什要这要做呢?报错为什么编译的时候有问题呢,首先我们先引入一个链接器的概念.

链接器

还记得我们在学习C程序的时候，从C代码到可执行文件经历的步骤是：

源代码 > 预处理器 > 编译器 > 汇编器 > 机器码 > 链接器 > 可执行文件

• 1

在最后一步需要把.o文件和C语言运行库链接起来，这时候需要用到ld命令。源文件经过一系列处理以后，会生成对应的.obj文件，然后一个项目必然会有许多.obj文件，并且这些文件之间会有各种各样的联系，例如函数调用。链接器做的事就是把这些目标文件和所用的一些库链接在一起形成一个完整的可执行文件
通过这个流程你也应该知道为什么在编译的过程中没事而在运行的时候就会报错了. 那我们为什么要设置Other Linker Flags呢 因为Other Linker Flags其实就是链接器工作时除了默认参数外的其他参数。

闪退的原因

苹果官方Q&A上有这么一段话：

The “selector not recognized” runtime exception occurs due to an issue between the implementation of standard UNIX static libraries, the linker and the dynamic nature of Objective-C. Objective-C does not define linker symbols for each function (or method, in Objective-C) - instead, linker symbols are only generated for each class. If you extend a pre-existing class with categories, the linker does not know to associate the object code of the core class implementation and the category implementation. This prevents objects created in the resulting application from responding to a selector that is defined in the category.
翻译:运行时的异常时由于静态库,链接器,与OC语言的动态的特性之间的问题,OC语言并不是对每一个函数或者方法建立符号表,而只是对每一个类创建了符号表.如果一个类有了分类,那么链接器就不会将核心类与分类之间的代码完成进行合并,这就阻止了在最终的应用程序中的可执行文件缺失了分类中的代码,这样函数调用接失败了.

other linker flags参数的作用

在前面我们说如果出现问题要在Other Linker Flags中加入-ObjC或者-all_load或者-force_load,我们为什么要加入这样的参数呢,他们究竟做了什么事呢?下面就是对这个三个参数的一个讲解.
ObjC
一般这个参数足够解决前面提到的问题,这个flag告诉链接器把库中定义的Objective-C类和Category都加载进来。这样编译之后的app会变大,因为加载了很多不必要的文件而导致可执行文件变大。但是如果静态库中有类和category的话只有加入这个flag才行,但是Objc也不是万能的,当静态库中只有分类而没有类的时候,Objc就失效了,这就需要使用-all_load或者-force_load了。
-all_load
-all_load会强制链接器把目标文件都加载进来，即使没有objc代码。但是这个参数也有一个弊端,那就是你使用了不止一个静态库文件，那么你很有可能会遇到ld: duplicate symbol错误，因为不同的库文件里面可能会有相同的目标文件 这里会有两种方法解决 1:用命令行就行拆包. 2:就是用下面的这个参数
-force_load
这个flag所做的事情跟-all_load其实是一样的，只是-force_load需要指定要进行全部加载的库文件的路径，这样的话，你就只是完全加载了一个库文件，不影响其余库文件的按需加载 .

总结

个人建议ObjC与force_load搭配使用比较好.

包含静态库时候需要在Target的Other linker flags里面加上值：-objC,-all_load,-force_load

对于64位机子和iPhone OS应用

解决方法是使用-all_load 或者 -force_load。

-all_load强迫链接器从它能看见的所有文档中加载所有的对象文件，甚至那些没有OC代码的文档。

-force_load适用于Xcode3.2+版本，它允许finer得到文档加载的控制。每一个-force_load操作必须跟着一个文档路径，文档中的每一个对象文件将会被加载。

-all_load就是会加载静态库文件中的所有成员，

-ObjC就是会加载静态库文件中实现一个类或者分类的所有成员，

-force_load（包的路径）就是会加载指定路径的静态库文件中的所有成员。

个人问题解决:

之前碰到一个问题

image

说file not found for libAppententiveConnect.a。因为该文件我已经删除，我始终无法明白为什么在archive工程总报错。最后发现force_load会强制加载

跟随在后头的路径。也就是$(BUILT_PRODUCTS_DIR)/libAppententiveConnect.a.随后删除这两个。工程就没有问题了.

最近在用pod引入新的三方库时,突然出现

!] The UQIGOU [Debug] target overrides the HEADER_SEARCH_PATHS build setting defined in `Pods/Target Support Files/Pods/Pods.debug.xcconfig'. This can lead to problems with the CocoaPods installation

- Use the `$(inherited)` flag, or

- Remove the build settings from the target.

[!] The UQIGOU [Debug] target overrides the OTHER_LDFLAGS build setting defined in `Pods/Target Support Files/Pods/Pods.debug.xcconfig'. This can lead to problems with the CocoaPods installation

- Use the `$(inherited)` flag, or

- Remove the build settings from the target.

[!] The UQIGOU [Release] target overrides the HEADER_SEARCH_PATHS build setting defined in `Pods/Target Support Files/Pods/Pods.release.xcconfig'. This can lead to problems with the CocoaPods installation

- Use the `$(inherited)` flag, or

- Remove the build settings from the target.

[!] The UQIGOU [Release] target overrides the OTHER_LDFLAGS build setting defined in `Pods/Target Support Files/Pods/Pods.release.xcconfig'. This can lead to problems with the CocoaPods installation

- Use the `$(inherited)` flag, or

- Remove the build settings from the target.

image

这么一大坨东西,查了下资料,发现是配置的问题,现在记录下解决方法,

进入对应的工程中,找到build setting对应的地址,这个地址就是你出现问题是弹出的内容,我这里的地址就是两个 'HEADER_SEARCH_PATHS'和 'OTHER_LDFLAGS',这两个就是上面那四个[!]里给出的,分别对应两种状态调试和发布([Debug]和[Release]),在对应的工程中把$(inherited)加进去即可,注意,去掉''号

image

image