文章目录一、先写一个可以复用的小模块二、第一种复用方式给源码和头文件1. 源码完全暴露2. 文件越来越多后使用麻烦3. 不利于模块独立维护三、第二种复用方式给 .o 和 .h四、头文件和目标文件分别负责什么1. 头文件负责告诉编译器“函数长什么样”2. .o 文件负责提供真正的函数实现五、只给 .o .h 的优点1. 可以隐藏源码实现2. 编译速度更快3. 接口和实现分离六、但 .o 文件多了以后仍然麻烦七、静态库的出现把多个 .o 打成一个包八、为什么 .a 不需要手动解包九、接口发布时应该给什么十、不要在 include 中写死路径十一、从源码到静态库的完整演进十二、总结上一篇我们讲了库的本质库是已经写好、成熟可复用的二进制代码。静态库和动态库虽然使用方式不同但它们都离不开一个共同基础目标文件.o。这篇文章不急着直接讲ar -rc libxxx.a *.o。我们先从最朴素的代码复用方式开始看一个库是如何从“发源码”一步步演进到“发.o .h”最终发展到“把多个.o打包成.a”的。一、先写一个可以复用的小模块假设我们写了一个简单的字符串工具模块提供两个函数my_strlen计算字符串长度my_strcmp比较两个字符串。头文件my_string.h#pragmaonceintmy_strlen(constchar*s);intmy_strcmp(constchar*s1,constchar*s2);实现文件my_string.c#includemy_string.hintmy_strlen(constchar*s){constchar*ends;while(*end){end;}returnend-s;}intmy_strcmp(constchar*s1,constchar*s2){while(*s1*s2*s1*s2){s1;s2;}return*s1-*s2;}使用者写一个main.c#includestdio.h#includemy_string.hintmain(){constchar*s1hello;constchar*s2hello;printf(len%d\n,my_strlen(s1));printf(cmp%d\n,my_strcmp(s1,s2));return0;}这时最直接的编译方式是gcc main.c my_string.c-omain ./main这就是最原始的复用把源码文件直接给别人。二、第一种复用方式给源码和头文件如果别人想使用我们的字符串工具我们可以把下面两个文件发给他my_string.h my_string.c使用者把自己的main.c和my_string.c一起编译即可gcc main.c my_string.c-omain这种方式简单直观但问题也很明显。1. 源码完全暴露如果这是你写的一个商业库或者你不希望别人直接看到内部实现发.c文件就不合适。头文件本来就是给别人看的因为它描述“怎么调用”。但实现文件不一定要给别人看。2. 文件越来越多后使用麻烦真实项目不会只有一个my_string.c可能还有my_stdio.c my_math.c my_log.c my_time.c my_net.c使用者每次编译时都要把这些.c文件全部写进命令里gcc main.c my_string.c my_stdio.c my_math.c my_log.c my_time.c-omain这很容易漏掉某个文件导致链接失败。3. 不利于模块独立维护如果库开发者和库使用者是两拨人使用者其实只关心有哪些函数可以调用 参数是什么 返回值是什么至于函数内部怎么实现不应该成为使用者必须关心的问题。这就引出了第二种方式只给头文件和目标文件。三、第二种复用方式给 .o 和 .h.c文件经过编译后会生成.o目标文件gcc-cmy_string.c-omy_string.o这里的-c表示只编译不链接。生成的my_string.o已经包含了my_strlen、my_strcmp的机器码实现。此时我们可以只把下面两个文件给使用者my_string.h my_string.o使用者编译自己的代码gcc-cmain.c-omain.o再把自己的目标文件和我们的目标文件链接起来gcc main.o my_string.o-omain这样程序照样能运行。四、头文件和目标文件分别负责什么这一步非常关键。很多链接错误本质上都是没分清头文件和库文件的职责。1. 头文件负责告诉编译器“函数长什么样”当main.c中写#includemy_string.h编译器能看到intmy_strlen(constchar*s);于是编译器知道my_strlen 是一个函数 它接收 const char * 它返回 int。所以main.c可以通过编译。但是头文件里只有声明没有函数实现。2. .o 文件负责提供真正的函数实现my_string.o中才有my_strlen的机器码。链接阶段链接器会发现main.o 里引用了 my_strlen my_string.o 里定义了 my_strlen 两者可以匹配。于是最终可执行程序就能生成。可以总结成一句话.h 解决编译阶段“能不能认识这个函数”的问题 .o/.a/.so 解决链接阶段“能不能找到这个函数实现”的问题。五、只给 .o .h 的优点相比直接发源码只发.o .h有几个好处。1. 可以隐藏源码实现使用者只能看到头文件里的接口看不到.c里的具体实现。2. 编译速度更快库开发者提前把库源码编译成.o。使用者不需要再编译库源码只需要链接.o。3. 接口和实现分离使用者只依赖头文件描述的接口库开发者可以在不改变接口的情况下优化内部实现。六、但 .o 文件多了以后仍然麻烦如果一个库只有一个.o文件直接给.o .h还可以接受。但真实库通常包含多个模块my_stdio.o my_string.o my_math.o my_log.o my_time.o使用者链接时就要写gcc main.o my_stdio.o my_string.o my_math.o my_log.o my_time.o-omain这带来三个问题命令太长。容易漏掉某个目标文件。发布和传输不方便。于是就需要一个“打包工具”把多个.o组织成一个文件。这就是静态库.a。七、静态库的出现把多个 .o 打成一个包静态库的本质可以非常直白地理解静态库 多个 .o 文件的归档包例如ar-rclibmyc.a my_stdio.o my_string.o my_math.o这条命令会把多个目标文件归档到libmyc.a中。之后使用者不需要关心里面有多少.o只需要链接这个库gcc main.c -L.-lmyc-omain这里的-lmyc会让链接器寻找libmyc.a也就是自动补上lib myc .a这就是为什么库文件命名要遵守libxxx.a的规则。八、为什么 .a 不需要手动解包.a是归档文件但它不是普通压缩包。使用者不需要先把它解开再一个个链接里面的.o。链接器认识.a格式。它会自动扫描静态库找到程序需要的目标文件并把相关代码合并进最终可执行程序。例如libmyc.a 中有 my_stdio.o my_string.o my_math.o如果你的main.c只调用了my_strlen链接器会从库中找到包含my_strlen的目标文件并把需要的部分纳入最终程序。所以静态库的价值不只是“少传几个文件”而是把一组目标文件变成一个可被链接器直接管理的整体。九、接口发布时应该给什么如果你要把一个库发布给别人最少需要给两类文件头文件告诉别人怎么调用 库文件提供真正实现典型目录结构可以这样组织myc/ ├── include/ │ ├── my_stdio.h │ └── my_string.h └── lib/ └── libmyc.a使用者编译时写gcc main.c -I./myc/include -L./myc/lib-lmyc-omain这里三个参数分别是-I告诉编译器去哪里找头文件 -L告诉链接器去哪里找库文件 -l告诉链接器要链接哪个库这三个参数会在后续文章反复出现。十、不要在 include 中写死路径有些初学者可能会这样写#include./myc/include/my_string.h这样虽然可能暂时能编译但不推荐。原因是源码和目录结构强绑定可移植性差。换一个项目路径就可能失效。正规做法应该通过-I指定头文件搜索路径。推荐写法是#includemy_string.h编译时指定gcc main.c -I./myc/include -L./myc/lib-lmyc-omain这样项目结构更清晰也更符合工程习惯。十一、从源码到静态库的完整演进我们把这篇文章的演进路线总结一下阶段 1给 .c .h 优点简单 缺点暴露源码文件多 阶段 2给 .o .h 优点隐藏源码使用者不必编译库源码 缺点.o 多了以后链接麻烦 阶段 3给 .a .h 优点多个 .o 打成一个库方便发布和链接 缺点库更新后程序需要重新链接这就是静态库出现的真实背景。十二、总结.o是理解库的关键。源文件先被编译成目标文件目标文件再被链接成可执行程序或库文件。头文件负责声明接口目标文件负责提供实现。当目标文件越来越多时就需要用ar把多个.o打包成静态库.a。下一篇我们正式进入静态库制作实战手写libmyc.a并用 Makefile 完成从编译、归档到打包发布的完整流程。
