CMake target_link_libraries如何影响链接顺序？调整后为何报错？

问题核心 #

你的问题本质是静态库的链接顺序规则和CMake处理INTERFACE目标链接属性的方式共同导致的。静态库的链接器处理逻辑对顺序极其敏感，第二种CMake配置恰好生成了错误的链接顺序。

链接器的静态库处理逻辑 #

链接器处理静态库（.a）时，只会提取能解决当前未定义引用的目标文件：

1. 先处理exe.o，产生未定义引用a。
2. 若先处理libd.a：此时没有未解决的d引用，链接器会直接跳过整个库。
3. 再处理liba.a：提取a.o解决a的引用，但a.o又产生未定义引用d，此时所有库已处理完毕，无法找到d的定义，报错。

反之，若顺序是liba.a在前、libd.a在后：

1. 处理liba.a时提取a.o，产生d的未定义引用。
2. 接着处理libd.a，提取d.o解决d的引用，链接成功。

两种CMake配置的差异 #

第一种配置（正常构建） #

add_library(a INTERFACE)
target_link_libraries(a INTERFACE
    ${PROJECT_SOURCE_DIR}/liba.a
    ${PROJECT_SOURCE_DIR}/libd.a
)

add_executable(exe exe.c)
target_link_libraries(exe PUBLIC a)

CMake会将INTERFACE目标a的链接项按原顺序展开到exe的链接列表中，最终生成的链接顺序是：
exe.o → liba.a → libd.a
完全符合链接器的要求，因此构建成功。

第二种配置（报错） #

add_library(a INTERFACE)
target_link_libraries(a INTERFACE
    ${PROJECT_SOURCE_DIR}/liba.a
)

add_executable(exe exe.c)
target_link_libraries(exe PUBLIC a ${PROJECT_SOURCE_DIR}/libd.a)

CMake在处理时，会将直接指定的静态库libd.a放在INTERFACE目标a的链接项（liba.a）之前，最终生成的链接顺序是：
exe.o → libd.a → liba.a
这恰好触发了链接器的顺序问题，导致未定义引用错误。

为什么直接gcc命令能成功？ #

你手动指定的gcc命令gcc -o exe exe.c liba.a libd.a明确使用了正确的链接顺序，因此链接器能正常找到所有定义。但CMake在混合INTERFACE目标和直接静态库时，自动生成的顺序不符合预期。

解决方法 #

1. 推荐方案：保持第一种配置，将libd.a放在INTERFACE目标a的链接列表中，让CMake维护正确的依赖关系，这也是INTERFACE目标设计的初衷——封装依赖细节。
2. 强制顺序方案：若必须在exe的链接列表中添加libd.a，需确保它在liba.a之后。可以通过调整CMake配置显式控制顺序，但这种方式破坏了依赖封装，不推荐。

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