如何诊断.so文件版本差异，解析链接器行为变化原因？

问题背景 #

我维护的一个预构建共享库（.so）包含如下核心逻辑：

int main(...) {
    bootstrap(...);
    return 0;
}

bootstrap(...) {
    /* 业务逻辑 */
    sc_main(...);
}

按设计，库中sc_main()是未定义符号，需要由链接该库的可执行文件实现。但存在一种遗留用法：可执行文件自行实现main()，这种用法在旧版本库下完全正常。

但当我用新版本工具链重新编译该库后，替换旧库链接可执行文件时，链接器因启用--no-allow-shlib-undefined选项，直接报错找不到sc_main()并拒绝完成链接。手动添加--allow-shlib-undefined选项后，生成的可执行文件能正常运行——这说明实际运行时根本不需要sc_main()，因为可执行的main()会覆盖库中的版本。但手动修改链接选项并非合理的长期解决方案。

已完成的检查 #

我用readelf对比了新旧版本的库文件，发现二者：

• 已定义和未定义符号完全一致，仅符号偏移量有差异
• 库的标志、依赖项也完全相同

虽然编译器版本变化导致生成的机器码不同，但理论上只有符号会影响链接行为，这让我无法理解为何新版本库会触发链接错误。

推测方向 #

我怀疑问题出在链接器选择main()符号的优先级逻辑上：

• 若链接器优先选用库中的main()，就会顺着调用链要求bootstrap()，进而触发对未定义符号sc_main()的检查
• 若链接器优先识别到可执行文件的main()，则整个调用链不会涉及sc_main()，也就不会触发错误

但我不确定链接器是否会深入分析共享库的依赖关系？会不会不是按函数粒度处理，而是按段/节的粒度进行符号依赖检查？

求助点 #

目前我无法复现旧版库的二进制文件，请问可以通过哪些具体的查询操作对比新旧库文件，找出导致链接需求差异的根本原因？

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