iOS 编译与链接实践

前言

温故而知新，重温编译原理知识，可以获得新的理解。

本文源于以前遇到的一个问题，在导出ipa的时候报错如下：

在解决过程中回顾有一些收获，于是有了这篇文章。
关键词：预处理、编译、汇编、链接、动态链接库、静态链接库。

正文

编译与链接过程

当我们进行编译时，会经过预处理、编译、汇编、链接的过程。
这是一段普通的c代码：

#include <stdio.h>
int main()
{
    puts("It's OK.");
    return 0;
}

用gcc对上面代码进行编译，整个编译过程如下：
编译流程图

这个过程需要几个gcc的指令处理：

1、预处理

gcc -E test.c -o test.i

2、编译

gcc -S test.i -o test.s

3、汇编

gcc -c test.s -o test.o

4、链接

gcc test.o -o test

指令解释

-E Only run the preprocessor
-S Only run preprocess and compilation steps
-c Only run preprocess, compile, and assemble steps
-o <file> Write output to <file>

静态连接与动态链接

1、静态链接

静态连接就是把静态连接库（.a文件）中的文件链接到可执行文件中；

.a文件是多个.o文件的组合；
.o文件是对象文件，里面是机器指令；
链接就是多个.o文件打包成可执行文件；

2、动态链接

动态链接就是仅在可执行文件中加入相关描述文件，执行时再动态加载相应的动态链接库；

3、链接过程

链接的过程，也就是符号重定位。
c/c++ 程序的编译是以文件为单位进行的，因此每个 c/cpp 文件也叫作一个编译单元(translation unit), 源文件先是被编译成一个个目标文件, 再由链接器把这些目标文件组合成一个可执行文件或库，链接的过程，其核心工作是解决模块间各种符号(变量，函数)相互引用的问题，对符号的引用本质是对其在内存中具体地址的引用，因此确定符号地址是编译，链接，加载过程中一项不可缺少的工作，这就是所谓的符号重定位。本质上来说，符号重定位要解决的是当前编译单元如何访问「外部」符号这个问题。

此段引用自linux 下动态链接实现原理，有更详细的原理介绍。

iOS相关

下图是Xcode工程的设置，接下逐步解析各个关键配置。

首先是Embedded Binaries的两个库，GPUImage.framework和lib.framework。
这两个是动态库，framework内容格式如下

接下来是Linked Frameworks and Libraries的依赖库，libstdc++.6.tbd。 tbd是dylib的优化版本，官方的解释如下：

the .tbd files are new "text-based stub libraries", that provide a much more compact version of the stub libraries for use in the SDK, and help to significantly reduce its download size

libXG-SDK.a是信鸽推送的静态链接库，libXXX.framework、GPUImage.framework是工程依赖的framework和GPUImage，libPods-Live.a是CocoaPods生成并管理的静态链接库。

在Build Phases的设置里面Check Pods Manifest.lock 设置的脚本会检查Podfile.lock 和 Manifest.lock 的差异，判断是否需要重新pod install
Embed Pods Frameworks、Copy Pods Resources 是另外两个脚本

问题排查

了解完工程的基本设置后，我们来定位前面提到的问题。
进行的操作是Archive -> Export -> Ad Hoc，提示的错误信息是 Found an unexpected Mach-O header code。
点击show logs，然后选择standard.log

log的描述是did not contain a "archived-expanded-entitlements.xcent" resource。

这个问题在stackoverflow也有人提问过，但是不是我遇到的情况。
stackoverflow给出的建议是：
Go to BUILD PHASES -> COPY BUNDLE RESOURCES, you will find there some framework. Remove from this section and add it to LINK BINARY WITH LIBRARIES. It will work..

检查工程的设置，发现是同事把一个静态库放到了Embedded Binaries项里面，然而静态库是不能打包到ipa里面。（静态库里的代码会编译链接到可执行文件，资源文件需要重新打包成一个bundle文件放入ipa包）

思考题🤔：CocoaPods很多第三方库是包括UI资源的，然而我们知道.a文件是不包括资源的，那么第三方库的资源如何处理的？

静态库与动态库

用几个测试样例和测试工程，来更好理解动态库和静态库。
介绍下测试工程和如何进行测试：
工程P为主工程，其中有4个子工程A、B、C、D，子工程打包的库为动态库或静态库，子工程之间存在依赖关系。
通过修改主工程的依赖库，以及子工程的依赖关系以及打包类型，测试动态库依赖静态库、静态库依赖动态库、静态库依赖静态库的情况。

在测试之前，先简单说明下静态库和动态库的打包方式，如下图

当选择Cocoa Touch Framework时，如果Mach-O Type 为 Static则打包的.framework文件为静态库；如果Mach-O Type 为 Dynamic，则打包的.framework文件为动态库。
当选择Cocoa Touch Static Library时，打包的.a文件为静态库。

静态库依赖静态库

测试环境
静态库A、B、C均采用Cocoa Touch Framework的打包方式。

静态库A：提供函数foo();
静态库B：提供函数call_foo_b(); 依赖静态库A，在call_foo_b中调用foo();
静态库C：提供函数foo()；

测试代码如下

#include "BLib.h"
#include "CLib.h"

- (void)testLib {
    NSLog(@"Test A.");
    call_foo_b();
    
    NSLog(@"Test B.");
    foo();
}

测试结果输出：

2016-12-20 09:54:12.931731 testLib[7671:4787567] Test A.
call_foo in BLib.
foo in ALib.
2016-12-20 09:54:12.931925 testLib[7671:4787567] Test B.
foo in ALib.

对于TestA，我们调用B的call_foo_b，然后在call_foo_b中又调用A的foo，打印的调用顺序为B->A，符合预期；
对于TestB，我们引入C的头文件，然后调用C的foo，打印的调用顺序是A，结果异常；

结果思考🤔
静态库的生成只有编译，没有链接；
当工程同时存在库A和C时，两个foo的函数符号在链接的时候，先引入者优先。验证方法是把工程依赖顺序从ABC改成CBA之后，结果输出变为：

2016-12-20 10:19:28.613791 testLib[7691:4795943] Test A.
call_foo in BLib.
foo in CLib.
2016-12-20 10:19:28.613871 testLib[7691:4795943] Test B.
foo in CLib.

静态库依赖动态库

测试环境
库A、B、C、D均采用Cocoa Touch Framework的打包方式。
* 动态库A：提供函数foo();
* 静态库B：提供函数call_foo_b(); 依赖动态库A，在call_foo_b中调用foo();
* 动态库C：提供函数foo()；
* 静态库D：提供函数call_foo_d(); 依赖动态库C，在call_foo_d中调用foo();

测试代码

#include "BLib.h"
#include "DLib.h"

- (void)testLib {
    NSLog(@"Test lib.");
    call_foo_b();
    call_foo_d();
}

测试结果

2016-12-20 10:36:09.389209 testLib[7707:4799800] Test lib. call_foo in BLib. foo in ALib. call_foo in DLib. foo in ALib.

对于第一组测试，我们调用静态库B的函数call_foo_b，在函数call_foo_b中调用动态库A的函数，正常；
对于第二组测试，我们调用静态库D的函数call_foo_d，在函数call_foo_d中调用动态库A的函数，异常；（预想中是调用动态库C的函数）

结果思考🤔
静态库的生成只有编译，没有链接；
那么在静态库D生成的过程中，只是确定了静态库D需要用到动态库中的foo函数；
当运行时，加载了动态库A、C，其中两个库均含有foo函数；动态链接器，按照加载的顺序，取到动态库A中的foo函数；
所以静态库B、D调用的foo函数均是动态库A中的foo函数。

验证： 我们调换Link Binary With Libraries 中A和C的位置，结果如下

2016-12-20 10:35:11.048034 testLib[7705:4799491] Test lib.
call_foo in BLib.
foo in CLib.
call_foo in DLib.
foo in CLib.

动态库依赖静态库

测试环境
库A、B、C、D均采用Cocoa Touch Framework的打包方式。

静态库A：提供函数foo();
动态库B：提供函数call_foo_b(); 依赖静态库A，在call_foo_b中调用foo();
静态库C：提供函数foo()；
动态库D：提供函数call_foo_d(); 依赖静态库C，在call_foo_d中调用foo();

测试代码

#include "BLib.h"
#include "DLib.h"

- (void)testLib {
    NSLog(@"Test lib.");
    call_foo_b();
    call_foo_d();
}

测试结果

2016-12-20 11:08:52.715415 testLib[7746:4810080] Test lib.
call_foo in BLib.
foo in ALib.
call_foo in DLib.
foo in CLib.

对于第一组测试，我们调用动态库B的函数call_foo_b，在函数call_foo_b中调用静态库A的函数，正常；
对于第二组测试，我们调用动态库D的函数call_foo_d，在函数call_foo_d中调用静态库C的函数，正常；

结果思考🤔
工程依赖里面只有动态库B、D，没有静态库A、C；
静态库A、C同名函数foo没有冲突；
这两个现象是原因是动态库在生成的过程中，除了编译还有链接的过程。如果动态库依赖静态库，在生成动态库时会将静态库的代码合并到动态库中。

扩展
如果动态库B、D的函数名字使用一样的call_foo，调用顺序和Link Binary With Libraries相关，与embeded的顺序无关；（embeded只是把动态库放入bundle中，关键在于链接器的顺序）

动态库依赖动态库

测试环境
动态库A、B、C、D均采用Cocoa Touch Framework的打包方式。

动态库A：提供函数foo();
动态库B：提供函数call_foo_b(); 依赖动态库A，在call_foo_b中调用foo();
动态库C：提供函数foo()；
动态库D：提供函数call_foo_d(); 依赖动态库C，在call_foo_d中调用foo();

测试代码

#include "BLib.h"
#include "DLib.h"

- (void)testLib {
    NSLog(@"Test lib.");
    call_foo_b();
    call_foo_d();
}

测试结果

2016-12-20 11:08:52.715415 testLib[7746:4810080] Test lib. call_foo in BLib. foo in ALib. call_foo in DLib. foo in CLib.

对于第一组测试，我们调用动态库B的函数call_foo_b，在函数call_foo_b中调用动态库A的foo函数，正常；
对于第二组测试，我们调用动态库D的函数call_foo_d，在函数call_foo_d中调用动态库C的foo函数，正常；

结果思考🤔
四个动态库都需要Link和Embeded；
与静态库依赖动态库的测试样例不同，这次虽然动态库A、C存在同名函数foo，但是调用的时候没有冲突。
动态库依赖动态库，在生成动态库的时候不会把依赖的动态库合并到动态库中。

静态库和动态库的依赖关系

静态库的生成只有编译，没有链接；
动态库的生成除了编译还有链接的过程；
如果动态库依赖静态库，在生成动态库时会将静态库的代码合并到动态库中；

静态库A依赖静态库B，使用时需要在Link Binary With Libraries引入静态库A、B；
静态库A依赖动态库B，使用时需要在Link Binary With Libraries引入静态库A和动态库B，并且在Embeded Binaries引入动态库B；
动态库A依赖静态库B，使用时需要在Link Binary With Libraries引入动态库A，并且在Embeded Binaries引入动态库A；
动态库A依赖动态库B，使用时需要在Link Binary With Libraries引入动态库A和B，并且在Embeded Binaries引入动态库A和B；

所有的代码都可以在这里找到。

扩展--Cocoa Touch Static Library的打包

Cocoa Touch Static Library打包出来的是.a格式的静态库，会把Link Binary With Libraries里面的静态库一起打包到.a静态库中，测试工程点我。

如何打包一个静态库，但是不包含其中的依赖库文件？

引入依赖库头文件即可，因为静态库只编译不链接。（但是如果Cocoa Touch Static Library 里面填入了第三方的静态库，会自动打包）

.a和.framework都是静态库格式，只是.framework格式包括了静态库文件、头文件、资源文件，故而更容易使用。

如何直接使用.a静态库，不要静态库的头文件？

Link Binary With Libraries中添加.a静态库；在使用静态库的函数前添加声明，但是不定义实现；这样编译时，会根据声明在全局查找定义；

总结

在写文章过程中，简单复习了下编译原理，深感程序员的技能树太过庞大，随便一个分支就够学习一辈子。平时开发遇到问题，习惯性的刨根问底，这次简单把这些知识串联起来，并和工程作相应结合，加深记忆。文章如有疏漏，敬请指出。