在linux下开发基于Intel IPP模块程序时，发现windows和linux对于静态库的依赖稍有差异，做个记录。
1. 编译：
抽象所碰到的问题:
可执行程序exe依赖于静态库liby，静态库liby依赖于libx。
windows下存在两种方案：
1. 在编译liby时，添加liby对于libx的依赖，则在编译exe时只需添加liby的依赖
2. 在编译liby时，不添加对libx的依赖，在编译exe时同时添加libx，liby的依赖
这两种方法window下都可行。但在采用1方法编译liby时，得到的liby大小会比2方法编译得到的liby要稍大，这也说明在方法1中，添加库的依赖时，liby把libx中的内容添加到库中。
而linux下只存在一种方案：
1.在编译liby时，不添加对libx的依赖，只能在编译exe时同时添加libx，liby的依赖。
2. 调用
可执行程序exe依赖于库liba和库libb，而库liba和库libb依赖于库libbase. liba,libb,libbase分别采用静态库和动态库形式输出，则最终exe的组织形式包括4种:
库libbase
void Libbase()
{
static int sIndex = 0;
printf("This is base dll or lib. sIndex is %d.\n", sIndex++);
}
库liba
void LibA
{
printf("This is lib or dll a.\n");
Libbase();
}
库libb
void LibA
{
printf("This is lib or dll b.\n"); Libbase();
}
可执行程序exe
void main()
{
LibA();
LibB();
}
1. 所有库都以静态库形式提供。结果相同。
linux和window下都输出:
This is lib or dll a. This is base dll or lib. sIndex is 0. This is lib or dll b. This is base dll or lib. sIndex is 1.
可以看出baselib在exe中只存在1份数据。
2. 所有库都以动态形式提供。结果相同。
linux和window下都输出:
This is lib or dll a. This is base dll or lib. sIndex is 0. This is lib or dll b. This is base dll or lib. sIndex is 1.
可以看出baselib在exe中只存在1份数据。
3. liba和libb以静态库形式提供， libbase以动态库形式提供。结果相同。
linux和window下都输出:
This is lib or dll a. This is base dll or lib. sIndex is 0. This is lib or dll b. This is base dll or lib. sIndex is 1.
可以看出baselib在exe中只存在1份数据。
4. liba和libb以动态库形式提供， libbase以静态库形式提供。结果不同。
linux下输出:
This is lib or dll a. This is base dll or lib. sIndex is 0. This is lib or dll b. This is base dll or lib. sIndex is 1.
可以看出baselib在exe中只存在1份数据。
windows下输出:
This is lib or dll a. This is base dll or lib. sIndex is 0. This is lib or dll b. This is base dll or lib. sIndex is 0.
可以看出baselib在exe中只存在2份数据，在dll中存在自己的分配空间。