我有一个共享对象/可执行文件，它静态和动态地链接到同一个库。
图书馆：liba.a和liba.so
liba.a创建使用：ar-rv liba.a.o，
包含libprint（）-->打印“static5”
liba.so创建时使用：gcc-shared-o liba.so-wl，-h，liba.so a.o，contains libprint（）prints“dynamic5”，
libprint2（）打印“dynamic6”
通过链接到存档和共享对象创建的EXE B：
当与gcc/linux链接时，我发现调用的实现总是来自liba.a。
我在liba.so，liba.a中定义了一个函数libprint（），它输出了一个不同的值。
据我所见，这是基于链接顺序：
gcc-o b.o liba.a liba.so-lc合同
/b/乙
静力学5
动态6
合同通用条款
/b/乙
动态5
动态6
为什么我们会故意需要链接到同一个库的.a和.so？以下内容：
如何使共享对象优先于存档，而不是链接顺序？
（-dy/-bdynamic似乎没有任何效果？）
一。如果缺少共享对象，则exe将失败，并出现错误
2.我们可以放置任何同名的虚拟共享对象，以满足dlopen（）
三。即使加载了共享对象，也会调用归档文件中的函数
更新2
以下是实际问题（如Statically and dynamically linking the same library中所述）
libd.so链接到共享对象liba.so
伦敦银行同业拆借利率
liba.so=>。/liba.so
B链接到共享对象libd.so和存档liba.a。
合同通用条款
后勤数据库B
libd.so=>。/伦敦银行同业拆借利率
liba.so=>。/liba.so
现在，b似乎先从archive调用函数，然后调用共享对象。
所以，即使我们更新liba.so，这些更改也不会反映在b中。
有办法解决这个问题吗？
最佳答案
当您将.a放在第一位时，链接器会在其中找到libprint()并链接它，但不会链接libprint2()。它继续搜索库以找到另一个函数，并在.so中找到它。
当您放置.so时，首先，两个函数都已找到并成功链接，因此无需再进一步查找它们。
应该没有理由链接同一个库的静态和动态版本，因为两者都应该提供在另一个库中找到的所有函数。
关于linux - 在Linux上静态和动态链接相同的库，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/6247483/