我有一个共享对象/可执行文件，它静态和动态地链接到同一个库 .
库：liba.a和liba.so
liba.a使用以下命令创建：ar -rv liba.a ao，包含libprint（） - > print“static5”liba.so使用以下命令创建：gcc -shared -o liba.so -Wl，-h，liba.so ao ，包含libprint（）打印“dynamic5”，libprint2（）打印“dynamic6”
通过链接到归档和共享对象创建的Exe b ：
当与GCC / Linux链接时，我发现调用的实现始终来自liba.a .
我在liba.so，liba.a中定义了一个函数 libprint() ，它打印出一个不同的值 . 从我看到的，这是基于链接顺序：
gcc -o b b.o liba.a liba.so -lc ./b static5 dynamic6 gcc -o b b.o liba.so liba.a -lc ./b dynamic5 dynamic6
为什么我们有意需要链接到同一个库的.a和.so？
除链接顺序外，我们如何让共享对象优先于存档？ （ -dy / -Bdynamic 似乎没有任何影响？）
1.如果缺少共享对象，则exe失败并显示错误2.我们可以放置任何具有相同名称的虚拟共享对象，只是为了满足dlopen（）3 . 即使加载了共享对象，也可以从存档被调用
Update #2 这是 actual 问题（如Statically and dynamically linking the same library中所述）
libd.so链接到共享对象liba.so ldd libd.so liba.so => ./liba.so b链接到共享对象libd.so和archive liba.a . gcc -o b b.o libd.so liba.a -lc ldd b libd.so => ./libd.so liba.so => ./liba.so
现在， b 似乎首先从归档调用该函数，然后是共享对象 .
因此，即使我们更新 liba.so ，这些更改也不会反映在 b 中 . 有没有办法解决 ？
1 回答
当您首先放置.a时，链接器会在其中找到
libprint()并链接它，但不会链接libprint2(). 它继续搜索库以便找到其他函数，并在.so中找到它 .当您首先放置.so时，会找到并成功链接这两个函数，因此无需再查找它们 .
应该没有理由链接同一个库的静态和动态版本，因为它们应该提供在另一个库中找到的所有函数 .