运行时和编译时使用的so库不同是否影响可执行文件执行

引子

        近日遇到如下问题:

        1.如果可执行文件依赖的so库在编译和执行阶段使用的名字一样，但是内容不一样，比如运行时相比于编译时在so库里增加了几个api定义，so库还可以正常使用吗？

        2.如果可执行文件依赖的so库在编译和执行阶段使用的名字一样，但是调用的api运行时相比于编译时定义发生了改变，api可以正常调用吗？

先上结论

        只要引用的api的类型没发生改变（返回类型，参数类型），即使引用的api内容发生了改变或者api在so库的位置发生了改变。可执行文件仍然可以正常引用。      

    可执行文件里只记录了so库的api的符号引用，在引用时不会校验api的大小，内容，所以即使api的内容或者位置发生改变，但只要类型不改变，就可以。      

    因为动态链接的过程涉及到符号解析和地址重定位。当可执行文件和动态库被编译时，编译器并不将函数的实际地址硬编码到可执行文件中。相反，它会在可执行文件中放置一个符号引用。在程序运行时，动态链接器（通常是 ld-linux.so）负责查找这些符号的实际地址，并进行重定位，以确保函数调用能够正确地定位到动态库中的相应函数。

代码实测

测试代码fun1.c

#include<stdio.h>

void testOne(){
    printf("enter testOne!\n");
}

void testTwo(){
    printf("enter testTwo!\n");
}

fun2.c

#include<stdio.h>

void testThree(){
    printf("enter testThree!\n");
}

void testFour(){
    printf("enter testFour!\n");
}

fun1.h

#pragma once 
int testOne();
void testTwo();

fun2.h

#pragma once 
void testThree();
void testFour();

将fun1.c,fun2.c编译为一个so

gcc -c -fpic fun1.c -o fun1.o //

gcc -c -fpic fun2.c -o fun2.o //

gcc -shared -o libfun.so fun1.o fun2.o

可执行文件测试main.c

#include"fun1.h"
#include"fun2.h"
#include<stdio.h>

int main(){
    printf("11\n");
    testOne();
    printf("22\n");
    testThree();
    return 0;
}

生成可执行文件：

gcc -o test main.c -I/workspace/codeAD/test/testSo -L/workspace/codeAD/test/testSo -lfun

readelf -d ./test

 可以看到可执行文件依赖的so库，libfun.so libc.so

可执行文件执行

修改fun1.c，增加一个testZero的api，同时修改testOne定义，但是testOne类型不变

fun1.c

#include<stdio.h>

void testZero(){
    printf("enter testOne!\n");
}

void testOne(){
    printf("enter testOne!\n");
    printf("enter testOne testOne!\n");
}

void testTwo(){
    printf("enter testTwo!\n");
}

重新编译fun1.o和libfun.so，fun2.o和可执行文件test不重新编译。

对比前后两个libfun.so，可以看到testOne这个api的value（value就是entry，入口点，可以大概理解为so库呗加载到内存后，此api相比于so库首地址的offset），size都发生了变化，但是符号引用没变。

再次运行可执行文件test，可以看到testOne接口被成功调用，使用了新的定义。

结论：只要api的类型不发生改变，即使运行时so库的接口相比于编译时定义和位置发生了改变，也不影响api调用。