如何确定库间依赖关系? [英] How to determine inter-library dependencies?

查看:146
本文介绍了如何确定库间依赖关系?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的项目由几个静态库组成,它们在最后一步链接在一起。现在我遇到了问题,图书馆的链接顺序很重要。(否则我得到一个未定义的符号链接器错误)。有时我碰到问题,我不得不重新排序链接库(-lcommon -lsetup -lcontrol等)。目前这是一个愚蠢的尝试和错误:重新排序,编译,检查错误,重新排序,编译等。

因此,我编写了一个小程序来向我展示库间依赖关系,并为我生成链接库的顺序。它从 nm 并删除

但是我的程序显示了我的循环依赖关系...我的错误是什么?



如果它们确实存在,我根本无法链接...所以在分析nm输出时错过了什么?或者正在分析nm输出而不是这种方式,以获得这些依赖关系?

  libcommon.a:
U _ZN15HardwareUnit23GetHardwareSerialNumberEv
libhardware.a:
00000484 T _ZN15HardwareUnit23GetHardwareSerialNumberEv
libsecurityaccess.a:
U _ZN15HardwareUnit23GetHardwareSerialNumberEv
---
libhardware.a:
U _ZN21ApplicationProfile26GetApplicationSettingsPathERK7QString
libsecurityaccess.a:
00004020 T _ZN21ApplicationProfile26GetApplicationSettingsPathERK7QString
U _ZN21ApplicationProfile26GetApplicationSettingsPathERK7QString


解决方案

链接库与循环依赖关系的另一个选择是为此使用特殊的链接器选项。 Man ld:

   - (档案 - )
- 开始组档案 - 结束组
档案应该是档案文件的列表。它们可能是
显式文件名或-l选项。

重复搜索指定的存档,直到不创建新的
未定义的引用。通常情况下,按命令行中指定的顺序仅搜索
一次。
如果需要该归档文件中的符号来解析在
后面出现的归档中由对象引用的未定义的
符号,则链接程序将无法解析
参考。通过对档案进行分组,他们都被重复搜索
,直到解决所有可能的参考。

使用此选项具有显着的性能成本。只有当两个或多个档案之间存在不可避免的循环引用
时,最好使用

尽管消除循环依赖关系总是更清晰。


My project consists of a couple of static libraries, which are linked together in a final step. Now I have the problem, that the link order of the library is important (otherwise I get an undefined symbol linker error). Sometimes I run into the problem, that I have to re-sort the linked libraries (-lcommon -lsetup -lcontrol etc). At the moment it's a stupid trial and error: re-sort, compile, check error, re-sort, compile and so on.

So I wrote a small program to show me the inter-library-dependencies and generates me the order of libraries to link. It reads in the defined ('T', 'B', etc) and undefined symbols ('U') from nm and removes the weak symbols ('w', 'W', 'v' and 'V') from the 'undefined symbol list'. Now it determines for every undefined symbol the library which resolves it.

But my program shows me circular dependencies... what's my mistake?

If they really exist, I could not link at all... so what did I miss, when analyzing the nm output? Or is analyzing the nm output not the way, to get these dependencies?

libcommon.a:
         U _ZN15HardwareUnit23GetHardwareSerialNumberEv
libhardware.a:
00000484 T _ZN15HardwareUnit23GetHardwareSerialNumberEv
libsecurityaccess.a:
         U _ZN15HardwareUnit23GetHardwareSerialNumberEv
---
libhardware.a:
         U _ZN21ApplicationProfile26GetApplicationSettingsPathERK7QString
libsecurityaccess.a:
00004020 T _ZN21ApplicationProfile26GetApplicationSettingsPathERK7QString
         U _ZN21ApplicationProfile26GetApplicationSettingsPathERK7QString

解决方案

Another option to link libraries with circular dependencies is to use a special linker option for that. Man ld:

   -( archives -)
   --start-group archives --end-group
       The archives should be a list of archive files.  They may be either
       explicit file names, or -l options.

       The specified archives are searched repeatedly until no new
       undefined references are created.  Normally, an archive is searched
       only once in the order that it is specified on the command line.
       If a symbol in that archive is needed to resolve an undefined
       symbol referred to by an object in an archive that appears later on
       the command line, the linker would not be able to resolve that
       reference.  By grouping the archives, they all be searched
       repeatedly until all possible references are resolved.

       Using this option has a significant performance cost.  It is best
       to use it only when there are unavoidable circular references
       between two or more archives.

It is always cleaner to eliminate the circular dependencies though.

这篇关于如何确定库间依赖关系?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆