C++链接器顺序问题：自定义main与项目目标文件子集链接难题

针对你遇到的问题——替换自定义main后二进制体积臃肿，链接依赖顺序混乱且-zmuldefs导致段错误，这里有几个实战性的解决思路：

1. 梳理最小依赖链，精准链接必要文件 #

首先要明确你的wrapper.cpp实际用到了哪些符号，然后只链接这些符号所在的目标文件和库，避免把整个项目都拉进来：

• 先分析wrapper.o的未定义符号：

  nm -D wrapper.o | grep ' U '
  

• 针对每个未定义符号，在项目的.o和.a文件中查找定义：

  find . -type f \( -name "*.o" -o -name "*.a" \) | xargs nm | grep ' T <你的符号名>'
  

• 递归追踪这些符号的依赖（比如符号A依赖符号B，就继续找B的定义），最终得到一个最小的文件列表。按依赖逆序链接（即被依赖的库放在前面，依赖它的文件/库放在后面），这能解决大部分顺序问题。

2. 启用链接器垃圾回收，自动剔除无用代码 #

GCC和Clang都支持通过编译/链接选项自动移除未使用的代码段，这对缩减体积效果显著：

• 编译所有源文件时添加：-ffunction-sections -fdata-sections，把每个函数和数据项放到独立的段中。
• 链接时添加：-Wl,--gc-sections，让链接器扫描并删除未被引用的段。
  注意：如果原项目没开这些选项，需要修改Makefile的编译规则，确保所有.o文件都用这两个参数编译。结合上面的最小依赖列表，体积能大幅缩减。另外，因为用了-zmuldefs，要留意重复符号中被保留的版本是否是正确的——垃圾回收不会误删被引用的符号，但如果符号解析顺序错了，还是会出问题。

3. 排查--start-group/--end-group导致的段错误 #

用--start-group/--end-group虽然能解决循环依赖，但在-zmuldefs下，链接器可能会选到错误的符号定义（比如某个符号有多个实现，链接器挑了一个不兼容的），这是段错误的根源。你可以用符号追踪工具定位问题：

• 链接时添加-Wl,--trace-symbol=<符号名>，比如追踪wrapper用到的关键函数：

  g++ -o fuzz_test wrapper.o ... -Wl,--trace-symbol=my_core_function -Wl,--trace-symbol=main
  

• 从输出中看哪个文件的符号被选中了，如果不是你期望的，调整该文件在链接列表中的位置（放到组内更靠前的位置，或者组外优先链接）。尽量只把有循环依赖的少数库放到--start-group/--end-group里，其他文件按正常顺序链接，减少符号选择的不确定性。

4. 用部分链接简化依赖结构 #

把wrapper.o和它直接依赖的目标文件先做部分链接，生成一个中间目标文件，再链接剩下的库：

ld -r wrapper.o dep1.o dep2.o -o wrapper_combined.o

这样做相当于把wrapper的依赖打包成一个整体，后续链接时只需要处理这个中间文件和其他库的依赖，能降低链接顺序的复杂度，也更容易控制符号解析的优先级。

5. 用链接器脚本精确控制符号解析 #

如果上面的方法都没解决，试试写一个简单的链接器脚本，明确指定符号的来源：
比如，强制某个符号从特定目标文件解析：

PROVIDE(my_critical_symbol = wrapper_dep.o:my_critical_symbol);
INPUT(wrapper_combined.o libA.a libB.a)

链接时用-Wl,-T,你的脚本名.ld指定脚本，这样能绕过-zmuldefs带来的符号选择随机性，确保正确的符号被选中。

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