1 Linux下so的特性
1.1 So的内容
nm可以看so的导出符号表
nm -C libsayhello.so
...
00000000000006a0 T sayhello
...可看到该so导出了一个函数，sayhello
1.2 App运行时加载的so名字
app链接时用到的so库，它在运行的时候就会去找同样名字的so库。比如app链接了libsayhello.so，运行时就会去找libsayhello.so。
我们也可以让app运行时去找另外的名字的so，方法是在编译libsayhello.so的时候，指定编译项soname，比如
-Wl,-soname,libwhatever.so.1那么当app链接了libsayhello.so之后，运行时会去找libwhatever.so.1。
2 不同so符号覆盖问题
2.1 动态库so同名函数覆盖
如果app链接了两个so，两个so里面存在同样签名的函数，但是实现不一样，那么只会保留一个实现。
比如假设libsayhello.so和libsayworld.so里面都有一个函数，叫void say(),
libsayhello.so
void say() { printf("hello
"); }
libsayworld.so
void say() { printf("world
"); }
当app里面调用了say的时候，要么输出hello，要么输出world，不可能即输出hello，又输出world。
假设是两个so分别引用了libsayhello.so和libsayworld.so，app再链接这四个so。
这种情况和app直接链接libsayhello.so和libsayworld.so是一样的。
当然如果是用dlopen，dlclose，dlsym这种动态加载so的方法，还是可以做到既输出hello，又输出world的。
2.2 动态库so同名变量覆盖
同名变量和同名函数也一样存在覆盖的问题。
而且更隐晦的是，变量和函数即使不在.h里定义，直接在.c/.cpp里面定义，也会导出到符号表，造成覆盖。
举个例子：
p1.so
//p1.h
void setInt_1(int i);
void sayInt_1();
//p1.cpp
#include <stdio.h>
#include "p1.h"
int myInt = 1;
void setInt_1(int i) { myInt = i; }
void sayInt_1() { printif("p1 myInt=%d
", myInt); }p2.so
//p2.h
void setInt_2(int i);
void sayInt_2();
//p2.cpp
#include <stdio.h>
#include "p2.h"
int myInt = 2;
void setInt_2(int i) { myInt = i; }
void sayInt_2() { printif("p2 myInt=%d
", myInt); }
main.c
#include "p1.h"
#include "p2.h"
int main(int argc, char** argv)
{
setInt_1(100);
sayInt_1();
sayInt_2();
return 0;
}
结果为：
p1 myInit=100
p2 myInit=100p1和p2都使用了一个同名的全局变量myInt，并且只在.c/.cpp文件里面定义，但是链接到so之后，就会只剩下一个全局变量myInt。所以，调用了p1.so里面的setInit_1函数之后，同时修改了p2.so里面的myInt值。
2.3 动态库so类静态变量覆盖
这个问题就更隐晦了！
如果两个so库的cpp文件里都包含了一个类A的定义，类里有一个静态变量s_a：
// p1.cpp & p2.cpp 新加入以下代码
class A
{
public:
A()
{
printf("A() this=%lld
", (long long)this);
m_int = new int();
*m_int = 1;
}
~A() { printf("~A()
"); /*delete m_int;*/ }
private:
static A s_a;
int* m_int;
};
A A::s_a;
main.c保持不变。
输出：
A() this=140279519260760
A() this=140279519260760
p1 myInit=100
p2 myInit=100
~A()
~A()可以看出，同一个对象先被构造了两次，再被析构了两次！
如果去掉注释，delete m_int的话将会crash。
2.4 静态库同名函数和同名变量覆盖
静态函数库的情况和动态库的情况类似。
2.5 导出脚本对符号覆盖的影响
前面之所以函数和变量会互相覆盖，是因为两个so都导出了相同的符号。
可以使用导出脚本，指定要导出的符号，未指定的就不会被导出。
如果我们指定了导出脚本为：
p1.map
{
global:
extern "C++"
{
"setInt_1(int)";
"sayInt_1()";
};
local:
*;
};p2.map
{
global:
extern "C++"
{
"setInt_2(int)";
"sayInt_2()";
};
local:
*;
};编译选项如：
g++ -shared -Wl,--version-script=p1.map -o libp1.so p1.o
g++ -shared -Wl,--version-script=p2.map -o libp2.so p2.o输出为：
A() this=139883050766416
A() this=139883052871760
p1 myInt=100
p2 myInt=2
~A()
~A()查看一下导出表，可知未导出变量：
nm libp2.so | grep " D "查看一下导出表，可知导出了两个函数
nm libp2.so | grep " T "
0000000000000756 T _Z8sayInt_2v
0000000000000740 T _Z8setInt_2i
分析整个流程，可知道两个so都分别只导出了两个函数, 各自里面的myInt变量和静态变量A::s_a都保留着，没有互相覆盖。
2.6 so之间符号覆盖的解决方案
简单的说就是不允许so之间出现符号覆盖，如果有符号覆盖基本可以肯定是出问题了。
那么万一用到的两个不同功能的so，比如是两个不同的开源项目的代码，由于是各自开发，出现了函数或变量名字相同的情况，应该怎么办呢？
答案简单粗暴，也最可靠，那就是改名。
话说回来，没考虑到符号冲突的so，质量要打个问号，能不用还是不要用。。。
如果是我们自己开发的so库，要注意
（1） 函数/变量/类加名字空间，如果是c函数就需要加前缀
（2） 不导出不需要的函数/变量/类
3 相同so版本兼容问题
3.1 新旧版本的兼容问题
动态库可能有新旧多个版本，并且新旧版本也可能不兼容。
可能有多个app依赖于这些不同版本的so库。
因此当一个so库被覆盖的时候，就可能出问题。
（1） 旧so覆盖新so，可能导致找不到新函数，
（2） 新so覆盖旧so，可能导致找不到旧的函数，
（3） 而更加隐蔽的问题是：新旧so里的同一个函数，语义已经不一样，即前置条件和效果不一样。
3.2 新旧版本的兼容关系
（1） 新版本完全兼容旧版本，只是新增了函数。
这种情况只需要新版本即可。
（2） 新版本删除了一些旧版函数，并且保持签名相同的语义相同（可能新增了函数）。
这种情况需要新旧版本同时存在。
（3） 新旧两个版本有一些相同签名但是语义不一样的函数。
这种情况是不予许的。
因为可能出现一个app必须同时依赖新旧两个版本，由于同一签名函数只能有一个实现，也就说另一个实现会被覆盖，就会出错。
3.3 新旧版本兼容的解决方法
由此我们知道，有两个解决方案：
（1） 新版本完全兼容旧版本，并保证新版本覆盖旧版本或者新旧版本共存。
这种方法太理想化。
实际情况下，新版本完全兼容旧版本比较难以做到，这要求函数一旦发布就不能改不能删，并且永远必须兼容。
（2） 新版本可以删除一些旧版函数，需保持签名相同的函数语义相同，并保证新旧版本共存。
这是可行的解决方法。
3.4 Linux的版本兼容解决方法
首先加版本号保证新旧版本可以共存，不会互相覆盖。版本号形如openssl.so.1.0.0。
其次新版本需保持和旧版本签名相同的函数语义相同。
这样已经可以解决问题了，但是还可以优化。
因为版本号分的太细，导致有很多的版本同时存在，其实不需要这么多版本。
仔细考虑一下：
（1） 如果新版本和旧版本的函数完全相同，只是fix bug：那么新版本需要替换掉旧版本，旧版本不需要保留。
（2） 如果新版本新增了函数：那么新版本可以替换掉旧版本，旧版本不需要保留。
（3） 如果新版本删除了函数：那么旧版本就需要保留。
如果linux系统下有新旧两个so，它怎么知道可不可以需不需要替换掉旧版本？
答案是通过版本号：
linux规定对于大版本号相同的一系列so，可以选出里面最新的so，用它替换掉其它的so。
这里所谓的替换，其实是建立了一个软链接，型如openssl.so.1，把它指向openssl.so.1.x.x.x系列so里面最新的那一个so。
4 Linux下的so规则
总结一下：
4.1 so导出规则
（1） 函数/变量/类加名字空间，如果是c函数就需要加前缀
（2） 不导出不需要的函数/变量/类
4.2 so版本号规则
版本号升级规则：
（1） 如果新旧版本函数完全相同，那么大版本号不变。
（2） 如果新版本新增了函数，那么大版本号不变。
（3） 如果新版本删除了函数，那么大版本号需要变。
（4） build号每次都变，小版本号按特性或需求变
此外还有两个版本号相关规则：
（1） 新版本不允许和旧版本函数签名相同语义不同。
（2） 建立软链接（形如openssl.so.1），指向大版本号相同的一系列so里面最新的so。app应当依赖于so的大版本号，不依赖于更细致的小版本号和build号。
4.3 App引用so的规则
（1） 不同库之间不能有同名全局函数/变量，静态函数/变量等。
否则会造成符号覆盖，基本可以肯定会出问题。
（2） 对于一个库，最好只引用一个版本。
如果需要引用同一库的多个版本，那么该库必须保证同名函数/变量的语义一致，除非是动态加载。
但是引用同一库的多个版本即使编译链接通过了，运行时依然可能会有潜在的问题，比如使用了同名的全局文件，信号量等，所以最好就是只引用一个版本。