iOS 编译与连接实践

时间  2021-08-12
标签 html linux c++ git 程序员 github xcode markdown ide 函数 栏目 iOS 繁體版
原文   原文链接

前言

温故而知新，重温编译原理知识，能够得到新的理解。html

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

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

正文

编译与连接过程

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

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

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

这个过程须要几个gcc的指令处理：程序员

  • 一、预处理
gcc -E test.c -o test.i
复制代码
  • 二、编译
gcc -S test.i -o test.s
复制代码
  • 三、汇编
gcc -c test.s -o test.o
复制代码
  • 四、连接
gcc test.o -o test
复制代码

指令解释github

-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>xcode

静态链接与动态连接

一、静态连接

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

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

二、动态连接

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

三、连接过程

连接的过程，也就是符号重定位。
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静态库；

在使用静态库的函数前添加声明，可是不定义实现； 这样编译时，会根据声明在全局查找定义；

总结

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

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程