静态库与动态库的思考

前言

在上文《编译与链接过程的思考》评论中暴走大牙提到了静态库和动态库依赖的问题,还在群里提了几个测试样例和测试工程。
大致介绍下测试工程和如何进行测试:
工程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静态库;
在使用静态库的函数前添加声明,但是不定义实现;

这样编译时,会根据声明在全局查找定义;

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,491评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,856评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,745评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,196评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,073评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,112评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,531评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,215评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,485评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,578评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,356评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,215评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,583评论 3 299
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,898评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,174评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,497评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,697评论 2 335

推荐阅读更多精彩内容