gpt4 book ai didi

linux - 建立相互依赖的共享库(Linux)

转载 作者:太空宇宙 更新时间:2023-11-04 09:34:49 24 4
gpt4 key购买 nike

我接管了一堆非常复杂的库和可执行文件 (Linux)。整个系统过去是使用静态库开发的,几年前这些库被迁移为共享库(-fPIC 等)。检查我发现的依赖项,有两个共享库:libA 和 libB:

  • libA 调用libB 的一些函数
  • libB 调用 libA 的一些函数

我想构建具有适当依赖关系的库:libA 依赖于 libB,而 libB 依赖于 libA。但是我不能给链接器“-llibB”,因为在 libA 的构建时 lib 还不存在

如果我在不依赖 libB 的情况下构建 libA(创建未解析的符号),我必须记住,如果我使用 libA,我还必须链接 libB,因为 libA 中的符号未定义。真烦人!

我正在寻找的是构建 libA 并告诉链接器在此时没有 libB 的情况下创建对 libB 的依赖性的可能性,这可能吗?

如何在不将 libA 和 libB 合并在一起的情况下解决我的问题?

问候,彼得斯


编辑:我发现,我可以直接生成一个空库(无需编写源代码):

gcc -shared -Wl,-soname,libB.so.$(MAJOR) -o libB.so

然后我可以构建 libA 添加:-lB 到构建命令。之后我删除了 libB.so。最后,安装完成后,libB 引用 libA,libA 引用 libB。

当然 MAJOR 编号必须与 libB 的 MAJOR 匹配,之所以如此,是因为主编号对于所有库都是通用的。

我只是在问自己有没有更合适的方式去做?

最佳答案

共享库之间的依赖关系在加载时才会解决,因此您可以使用以下行进行链接:

gcc -shared -Wl,-soname,libA.so.$(AMAJOR) -o libA.so
gcc -shared -Wl,-soname,libB.so.$(BMAJOR) -o libB.so

然后

gcc -o myProgram a.o b.o c.o libA.so libB.so

当您加载(运行)myProgram 时,动态加载程序将跟踪未满足的依赖项并在两个共享对象中查找符号。 -shared 选项实际上是一个 non-complaint-about-unresolved-symbols 标志,它允许构建一个没有所有已解析符号的 ELF 文件。

此处可能发生的另一件事是未安装 库。您试图在没有正确路径的情况下执行它们,并在执行时获得未解析的符号(来自 myProgram)。一种解决方案是使用以下命令运行 myProgram:

LD_LIBRARY_PATH=. myProgram

export LD_LIBRARY_PATH=/path/to/libraries
myProgram

在 linux 中,库缓存在系统数据库中,因此加载共享库的速度很快。数据库由 soname 索引,要重新生成数据库,您必须以根用户身份使用命令 ldconfig(8)

ldconfig

其他环境可能根本不使用ldconfig(8)(例如solaris)

关于linux - 建立相互依赖的共享库(Linux),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/27817560/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com