一、重构代码消除循环依赖 (Refactor to Eliminate Circular Dependency)

核心思想: 循环依赖通常表明设计存在问题，两个模块（库）职责不清，互相知晓对方过多细节。

定义一个新的、更小的接口库（Interface Library）或抽象基类，让原来互相依赖的库 LibA 和 LibB 都只依赖这个新的接口库，而不是直接依赖彼此。各自实现接口并与之交互。如果两个库联系过于紧密，考虑将它们合并成一个更大的库。或者重新划分职责，分析依赖关系，看看是否可以调整模块边界，使得依赖变为单向的（例如，LibA -> LibB，而不是 LibA <-> LibB）。

二、使用链接器选项 (Workaround with Linker Options)

如果暂时无法重构，可以使用链接器提供的功能来强制完成链接过程。这主要是针对静态库 (.a) 的循环依赖。

GNU ld 的 Group 选项 (–start-group, –end-group) 告诉链接器反复扫描指定组内的库，直到所有可能的符号都被解析或确认无法解析。

1
2
3
4
5
6
7
gcc -o myprogram main.o \
    -L/path/to/libs \ # 指定库搜索路径
    -Wl,--start-group \
    -lA \
    -lB \
    -Wl,--end-group \
    -lOtherNonCyclicLib # 组外的库

主要解决静态库的循环依赖。对于动态库 (.so)，链接时通常只需要存根信息，运行时才加载，情况不同。方便快速解决问题，无需修改源码，不过是一种“打补丁”的方式，掩盖了设计问题，增加了链接复杂性和潜在的时间开销。

三、调整链接顺序 (Mitigation by Adjusting Link Order)

对于某些简单的、非严格意义上的循环依赖（例如，A 调用 B，B 调用 A，但 A 对 B 的调用发生在 B 被完全链接之后的部分），巧妙地调整库的链接顺序有时可以意外奏效。

或者，简单干脆地把依赖库复制粘贴几份!!!

四、架构方案：延迟绑定/动态加载 (Architectural Solutions - Lazy Binding/Dynamic Loading)

不在链接时解析所有符号，而是在程序运行时才加载库并解析符号。这从根本上避免了链接阶段的循环依赖问题。

动态库 + 运行时链接: 使用 .so (Linux) 或 .dll (Windows) 动态库，并通过 dlopen/dlsym (POSIX) 或 LoadLibrary/GetProcAddress (Windows) 等 API 在运行时显式加载库和获取函数地址。

将功能模块化为独立的插件，主程序通过统一接口加载和调用插件。

增加了运行时的复杂性，需要手动管理库的加载和卸载，错误处理更复杂。通常需要较大的架构调整。

五、参考链接