当一个静态库依赖于另一个静态库时，是否需要指定链接依赖关系？

问题描述：

一般问题可以表述为 - 如果静态库lib1依赖于另一个静态库lib2，是否需要将lib2指定为lib1的链接器依赖项，或者链接依赖性只需要在库针对某些应用程序链接时指定（以及那么每个使用lib2的应用程序都应该链接到lib1）？当一个静态库依赖于另一个静态库时，是否需要指定链接依赖关系？

具体来说，我有一堆静态库和应用程序，它们之间的一些依赖，这样的：

makeall.pro：

TEMPLATE = subdirs 
CONFIG += ordered 
SUBDIRS = coreLib \ 
    anotherLib \ 
    .... 
    someApp 

anotherLib.depends = coreLib 
someApp.depends = coreLib anotherLib

coreLib.pro

TEMPLATE = lib 
CONFIG += staticlib 
TARGET = coreLib 
#... some .cpp and .h

anotherLib .pro

TEMPLATE = lib 
CONFIG += staticlib 
INCLUDEPATH += PATH_TO_CORE_LIB_INCLUDES 
DEPENDPATH += PATH_TO_CORE_LIB_INCLUDES 
TARGET = anotherLib

个

#Lines在问题

someApp.pro

TEMPLATE = app 
DESTDIR = ..\bin 
INCLUDEPATH += PATH_TO_CORE_LIB_INCLUDES PATH_TO_ANOTHER_LIB_INCLUDES 
DEPENDPATH += PATH_TO_CORE_LIB_INCLUDES PATH_TO_ANOTHER_LIB_INCLUDES

#Lines问题

我应该在问题使用线：

anotherLib.pro

(nothing required)

someApp.pro

PRE_TARGETDEPS += ../bin/coreLib.lib ../bin/anotherLib.lib

OR：

II。 anotherLib.pro

PRE_TARGETDEPS += ../bin/coreLib.lib

someApp

PRE_TARGETDEPS += ../bin/anotherLib.lib

OR

III。 anotherLib.pro

PRE_TARGETDEPS += ../bin/coreLib.lib

someApp.pro

PRE_TARGETDEPS += ../bin/coreLib.lib ../bin/anotherLib.lib

答

构建静态库时，不需要链接到其他静态库中。

当构建一个可执行文件时，您需要包含代码所依赖的代码和库的所有库。图书馆通常需要按照正确的顺序。如果lib foo依赖lib c，那么您必须使用-lfoo -lc。

在遥远的过去，静态库中的目标文件的顺序很重要，但没有更多。

完美，谢谢！如果库的顺序错误 - 它根本就不会链接，对吧？ – 2013-05-02 20:18:48

即使在库中定义了符号，您也会得到未定义的符号。 – 2013-05-02 20:20:24

包括您的库名或路径--start-group和--end-group之间的链接将导致您的链接器不断查找您的库，直到解决所有依赖关系。 – Barracuda 2013-05-02 20:39:32

答

，找出最好的方法是尝试编译应用程序，并寻找提供已包含所有你已经使用了外部库的编译错误。 编译器是你最好的朋友。

它编译我说的三种配置中的任何一种。我关心两件事 - 1.不要添加额外的依赖关系。 2.当图书馆的音乐被修改时，确保整个项目的正确构建。 – 2013-05-02 19:57:47

如果不使用其中一个库中的符号，则不必担心额外的依赖关系，它会自动被编译器丢弃，或根本不查看编译器的手册。还要管理库之间的依赖关系，包括所有这些都是你的程序直接依赖的那些，以及你的库依赖于它们之间的依赖关系。--start-group和--end-group更多信息请查看'ld'手册页。 – Barracuda 2013-05-02 20:30:46

当一个静态库依赖于另一个静态库时，是否需要指定链接依赖关系？

相关推荐