交叉编译时在install阶段调用strip的可移植方案问询

问题背景 #

执行install -s时，工具会直接调用主机系统的strip程序，这在交叉编译场景下会破坏编译结果——因为我们需要调用目标平台专属的strip版本，而非主机自带的版本。目前已知的解决方式分平台：GNU install用--strip-program参数指定路径，BSD install则依赖STRIPBIN环境变量，但两者实现逻辑完全不同。

1. 为什么GNU和BSD的实现方式差异这么大？ #

核心原因是两者属于完全独立的工具链生态，维护团队的设计理念和历史决策不同：

• GNU工具链（如coreutils中的install）更偏好命令行参数配置行为，认为参数更直观，脚本可读性更强；
• BSD系工具则习惯用环境变量传递这类底层工具路径，这是BSD工具链的一贯设计风格，很多工具都依赖环境变量调整行为。
  此外，两者的开发过程没有强制对齐的标准约束，自然形成了不同的实现方案。

2. 为什么不沿用Makefile常用的STRIP环境变量？ #

这和install工具的定位有关：

• install是独立的系统工具，并非Makefile的专属组件，它需要在脱离Makefile的shell脚本等场景下也能正常工作，所以设计时没有优先绑定Makefile的变量规范；
• 另外，STRIP变量的典型用法是让Makefile直接调用strip工具，而install -s是让install内部调用strip，两者的使用场景有差异，工具维护者认为没必要强行对齐这个变量。

3. 有没有统一的解决方法？ #

有三种可靠的跨平台方案：

方案一：拆分步骤，手动调用strip

完全避开install -s的自动strip功能，先执行安装，再手动用指定的STRIP处理文件：

install mybinary /usr/local/bin/
${STRIP} /usr/local/bin/mybinary

这种方式兼容性拉满，不管是GNU还是BSD环境都能正常工作，且天然适配Makefile中STRIP变量的使用习惯。

方案二：检测环境，动态适配

在脚本或Makefile中先判断当前install的类型，再对应使用参数或环境变量：

if install --help | grep -q --strip-program; then
    # GNU install
    install -s --strip-program="${STRIP}" mybinary /usr/local/bin/
else
    # BSD install
    STRIPBIN="${STRIP}" install -s mybinary /usr/local/bin/
fi

这种方式保留了install -s的便捷性，但需要额外的环境检测逻辑。

方案三：借助构建工具自动处理

如果项目用autotools（如configure脚本）、CMake等跨平台构建工具，它们会自动适配不同平台的install工具差异，你只需要指定STRIP变量即可，无需手动处理细节。

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