未解析符号问题：QMake与MSBuild行为差异排查

我有三个项目：A（可执行文件）、B和C（均为静态库）。B中的Add(int, int)函数供A调用，而Add的实现依赖C中的AddImpl函数。

按照我对C的理解，编译A时只需链接B即可——因为B作为静态库，编译时应该已经把C中AddImpl的代码合并进来了。这套逻辑在Visual Studio 2019/2022中可正常运行，但在Qt Creator（使用相同MSVC编译器）中却无法工作。这是QMake的Bug，还是我对C的理解存在遗漏？

各项目代码 #

A项目 #

A.pro

QT -= gui
CONFIG += c++11
SOURCES += A.cpp
LIBS += -Lpath/to/B -lB
INCLUDEPATH += path/to/Bheader

A.cpp

#include <B.h>
int main() {
    Add(1, 2);
    return 0;
}

B项目 #

B.pro

QT -= gui
CONFIG += c++11
SOURCES += B.cpp
LIBS += -Lpath/to/C -lC
INCLUDEPATH += path/to/Cheader

B.h

int Add(int, int);

B.cpp

#include <C.h>
#include "B.h"
int Add(int a, int b) {
    return AddImpl(a, b);
}

C项目 #

C.pro

QT -= gui
CONFIG += c++11
SOURCES += C.cpp

C.h

int AddImpl(int, int);

C.cpp

int AddImpl(int a, int b) {
    return a + b;
}

Visual Studio中的配置方式 #

在Visual Studio中，我通过右键项目进入「属性/ Librarian」，将C.lib设置为「附加依赖项」，并将C的输出路径设置为「附加库目录」；A的「附加依赖项」在「属性/ Linker/ Input」中设置，「附加库目录」在「属性/ Linker/ General」中设置。

另外我注意到，qmake在链接阶段使用link.exe编译静态库，而msbuild使用lib.exe，不知这是否是导致差异的原因。

问题原因分析 #

首先纠正一个理解误区：静态库本身不会自动合并依赖的其他静态库代码。Visual Studio中能正常运行，是因为你在B项目的Librarian配置中添加了C.lib作为附加依赖项——这一操作会让VS在生成B.lib时，将C.lib的代码合并到B.lib中，最终B.lib包含了自身和C的所有必要代码。

而Qt Creator中使用qmake时，静态库项目里的LIBS += -lC配置是无效的：qmake在生成静态库时，会忽略LIBS中的依赖静态库配置，它只会在生成可执行文件或DLL时才会处理这些链接项。同时，qmake用link.exe生成静态库的逻辑，和msbuild用lib.exe的处理不同，link.exe默认不会将依赖的静态库内容合并到目标静态库中。

解决方案 #

方案一：让A同时链接B和C #

修改A.pro，直接添加对C库的链接：

QT -= gui
CONFIG += c++11
SOURCES += A.cpp
LIBS += -Lpath/to/B -lB -Lpath/to/C -lC
INCLUDEPATH += path/to/Bheader

方案二：合并C库到B库中 #

修改B.pro，明确指定为静态库项目，并添加自定义步骤，用lib.exe将C.lib合并到B.lib中：

QT -= gui
CONFIG += c++11 staticlib
SOURCES += B.cpp
INCLUDEPATH += path/to/Cheader

# 指定依赖的C库路径
C_LIB = path/to/C/C.lib
POST_TARGETDEPS += $$C_LIB

# 编译完成后合并静态库
QMAKE_POST_LINK += "lib.exe /OUT:$$TARGET $$TARGET $$C_LIB"

添加CONFIG += staticlib可以让qmake更准确地处理静态库项目的构建流程。

方案三：切换到CMake构建（可选） #

如果项目允许，改用CMake构建会更直观地处理静态库依赖，CMake默认会自动传递静态库的依赖链。

内容的提问来源于stack exchange，提问作者SynchronizX