共享与静态库链接：OpenSSL版本冲突时静态链接libc可行性咨询

问题1：是否可以将自有依赖库libc替换为静态库版本消除冲突警告？ #

可以，但必须满足编译配置要求，不是简单替换文件就能生效。
你当前遇到的警告本质是动态链接器在加载进程全局符号表时，检测到两份不兼容的OpenSSL库导出了大量同名、但ABI不匹配的符号：主程序加载了libssl.so.1.0.1，你自研的libc.so又会加载libssl.so.0.9.8，两个版本无兼容保证，一旦跨库错调符号会直接触发内存错误，因此动态链接器主动抛出警告。
如果要通过静态库方案解决，必须做到两点：

• 编译自研libc的静态库libc.a时，直接将OpenSSL 0.9.8静态链接到libc.a内部，不要让libc.a保留对外部libssl.so.0.9.8的动态依赖
• 编译时通过链接器版本脚本控制符号导出，仅保留libc本身需要对外提供给其他模块调用的接口，将所有内嵌的OpenSSL 0.9.8相关符号全部设为本地可见、不对外暴露。

满足这两个前提的情况下，动态链接器在加载时完全感知不到内嵌的OpenSSL 0.9.8符号，不会触发版本冲突警告，两份OpenSSL在进程内各自运行互不干扰。
可以参考如下最简版本脚本示例（文件名比如libc.map），配合编译参数使用即可实现符号控制：

LIBYOURC_1.0 {
    global:
        # 此处填写所有libc需要对外暴露的接口名，例如
        yourlibc_init;
        yourlibc_do_task;
    local:
        *;
};

编译时追加链接参数-Wl,--version-script=libc.map即可生效。

问题2：使用静态库libc.a时，原本依赖libc.so的liba.so、libb.so是否仍可正常运行？ #

默认直接替换文件的情况下不能正常运行，需要调整链接流程，有两种成熟的落地方式：

• 方案一：重新编译liba.so和libb.so，链接阶段直接把前面处理好的、内嵌了隐藏版OpenSSL 0.9.8的libc.a链入两个动态库内部。编译时同样建议给liba、libb.so加符号导出控制，避免内嵌的OpenSSL符号泄露。编译完成后liba、libb不再依赖外部的libc.so，加载时不会触发libssl.so.0.9.8的加载逻辑，和主程序的OpenSSL 1.0.1完全隔离，可正常运行。
• 方案二：把处理好的libc.a（内嵌隐藏版OpenSSL 0.9.8）重新打包为新的动态库libc.so，保持新动态库对外导出的接口和原libc.so完全一致。由于新的libc.so已经把OpenSSL 0.9.8静态内嵌、且隐藏了相关符号，不再依赖外部的libssl.so.0.9.8，这种情况下不需要重新编译原来的liba.so、libb.so，直接替换旧的libc.so即可正常运行，同时不会触发冲突警告。

重要提醒：此处操作的libc是你自研的业务动态库，不要和系统自带的glibc（即系统路径下的libc.so.6）混淆。绝对不要尝试静态链接系统glibc，会触发堆管理、IO接口的跨模块冲突，导致程序崩溃。

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