为什么要剥离库的全部符号？全符号剥离的库适用场景是什么

我时常发现开发者对如何剥离库的调试符号存在误解：很多人会错误执行strip libfoo.so.1.0.0命令，而非正确的strip -g libfoo.so.1.0.0。后者仅剥离调试符号，是大家通常想要的操作；而前者会剥离所有非运行必需的符号，很多人误以为会彻底导致库无法链接使用，实际这个操作有非常多实用场景。

关于strip操作的认知误区澄清 #

首先要纠正一个普遍的偏差：默认无参数的strip并不会把库运行需要的所有符号都删掉导致完全无法调用：

• strip -g仅移除调试信息段，静态符号表、动态符号表都会完整保留，适合开发阶段需要保留排查问题能力的场景
• 无参数的strip仅会移除静态符号表、调试信息、行号表这类仅用于开发调试、不影响程序运行的段，动态链接、运行时加载必须的动态符号表、重定位表都会完整保留，共享库的正常动态加载、调用完全不受影响，只有需要对静态库做静态链接的时候才会因为静态符号表缺失报错。

全strip操作的实用场景 #

• 闭源软件交付场景：不管是共享库还是最终的二进制程序，全strip之后体积可以减少30%甚至更多，同时内部的函数名、变量名等符号信息都会被移除，大幅提升逆向工程的门槛，避免内部实现逻辑泄露，是闭源软件发行前的标准操作。
• 运行时插件/动态加载组件场景：比如浏览器插件、程序的功能扩展插件这类只需要暴露少数约定好的入口函数的组件，全strip之后可以把所有内部函数的符号都抹掉，既减少体积，还能避免不同插件之间的内部符号命名冲突，不会出现两个插件都有同名内部函数导致调用异常的问题。
• 安全合规场景：很多对安全要求高的行业，要求交付的二进制不能保留任何调试信息、内部符号信息，避免攻击者通过符号信息快速定位漏洞利用的入口，也避免内部开发的命名规范、模块逻辑等信息泄露，这种场景下全strip是强制要求的操作。
• 嵌入式固件开发场景：嵌入式设备的固件存储空间通常非常有限，全strip之后可以有效压缩固件体积，而且嵌入式固件通常是一次性编译完成的最终镜像，后续不会再做链接操作，全strip不会影响最终固件的运行，是嵌入式开发里非常常见的优化操作。

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