lld链接静态库必须按“依赖者在前、被依赖者在后”顺序排列，即被依赖的库需放在依赖它的库之后；多级依赖须完整列出，循环依赖可用--start-group/--end-group解决。
lld链接静态库必须按“被依赖者在后”排列
lld（LLVM的内置链接器）和传统ld一样，对静态库顺序敏感：它从左到右单次扫描，每个.a文件只尝试解析**当前已知未定义符号**。如果libA.a调用了libB.a里的bar_init，但命令里写成-lB -lA，那么处理libB.a时没有未定义符号可解，等轮到libA.a时，bar_init仍处于未定义状态，最终报undefined reference to 'bar_init'。
正确写法必须是-lA -lB——即“依赖者在前，被依赖者在后”。这和你读代码时的直觉相反，但符合链接器实际行为逻辑。
- 多级依赖如 A → B → C，顺序只能是
-lA -lB -lC，不能省略中间项 -
-L只影响-l查找路径，不改变扫描顺序；多个-L也按从左到右生效 - 同一库重复出现（如
-lA -lB -lA）不会自动去重，可能引入重复定义或符号冲突
遇到循环依赖时，用--start-group/--end-group绕过顺序限制
当libA.a和libB.a互相调用函数（A ←→ B），单次扫描必然失败。lld支持--start-group和--end-group，让链接器在组内反复扫描，直到所有符号收敛。
命令示例：clang main.o -Wl,--start-group -lA -lB -Wl,--end-group -o app。注意-Wl,前缀不可省，逗号也不能漏；组内库顺序任意，-lB -lA或-lA -lB都行。
- 该机制本质是多轮左→右扫描，不是“忽略顺序”，所以性能略低于普通顺序链接
- 不要滥用：仅在真实存在循环依赖时启用；否则掩盖设计问题，增加后续维护成本
- CMake中对应写法是
target_link_libraries(myapp PRIVATE -Wl,--start-group libA.a libB.a -Wl,--end-group)
混合链接静态库和动态库时，静态库仍要守序，且位置更关键
即使命令里同时有-lfoo（静态）和-lbar（动态），静态库的顺序规则依然生效。因为动态库只提供符号表供运行时解析，而静态库内容会直接拷贝进二进制；若libstatic.a依赖libshared.so中的符号，那libstatic.a必须出现在libshared.so之前（即-lstatic -lshared），否则链接阶段就卡在静态部分。
- 动态库之间无顺序要求，但动态库不能解决静态库的未定义符号——除非你显式用
--no-as-needed强制加载 - 常见陷阱：把
-lstdc++或-lc等系统库放在最右边是安全的；但若自定义静态库依赖它们，这些系统库必须排在自定义库之后 - 验证方法：用
llvm-nm -gC libstatic.a | grep ' U '看它依赖哪些符号，再用llvm-nm -gC libshared.so | grep ' T '确认对方是否提供了对应定义
最容易被忽略的底层细节：静态库打包方式和符号可见性
就算顺序全对，仍可能链接失败——问题常出在静态库本身。lld默认只提取能解决当前未定义符号的目标文件（.o），而ar打包顺序、是否用了-fPIC、甚至编译时是否加了-g都可能影响符号导出。
- 用
llvm-ar -t libfoo.a检查归档内目标文件顺序；某些旧版ar（如ar q）不保证符号索引完整，建议统一用llvm-ar rcs - 若静态库由C++代码生成，确保所有源文件都用相同ABI编译（比如都用
-std=c++17），否则llvm-nm看到的符号名（mangled name）对不上 -
__attribute__((visibility("hidden")))或-fvisibility=hidden会让符号不进入归档索引，导致链接器“看不见”——调试时先试-fvisibility=default临时排除
顺序只是表象，真正决定链接成败的是符号能否在扫描窗口内被匹配上。一旦出错，别急着调顺序，先用llvm-nm盯住具体哪个符号没落进归档、谁定义了它、谁又在引用它。
