在RHEL 6上构建运行C++17/Boost程序且不干扰原有C++98程序咨询

1. 构建环节无干扰实现方法 #

• 为新增的C17程序编写独立的构建脚本，完全不修改原有C98程序的makefile、shell脚本等构建配置，从根源避免互相影响
• 构建C++17程序前，仅在当前构建的shell会话内执行DTS 8环境激活命令：source /opt/rh/devtoolset-8/enable，该命令只会修改当前会话的PATH、CC、CXX等环境变量，会话结束后自动恢复系统默认工具链，不会全局生效
• 将新版Boost单独编译安装到独立的专属目录，例如/opt/boost-latest，禁止安装到系统默认路径。在C++17程序的makefile中显式指定头文件搜索参数-I/opt/boost-latest/include、库文件搜索参数-L/opt/boost-latest/lib，完全屏蔽系统默认的旧版Boost配置
• 所有和新工具链、新版Boost相关的环境变量配置，仅作用于C++17程序的构建脚本生命周期内，旧程序的构建流程全程不引入任何新配置，两者完全隔离

2. 运行时非默认共享库加载方法 #

• 优先采用rpath硬编码方案：在C++17程序的链接参数中添加-Wl,-rpath=/opt/rh/devtoolset-8/root/usr/lib64:/opt/boost-latest/lib，将依赖库的专属路径直接写入程序的运行时搜索段，该配置仅对当前编译的程序生效，完全不会影响其他程序的库加载逻辑
• 也可选择包装脚本方案：编写单独的启动脚本，执行程序前先临时设置LD_LIBRARY_PATH=/opt/rh/devtoolset-8/root/usr/lib64:/opt/boost-latest/lib:$LD_LIBRARY_PATH，再启动程序本体，该方案适合需要频繁调整依赖路径的调试场景
• 程序编译完成后，可执行ldd 新程序路径命令验证所有依赖的共享库是否都指向了正确的非默认版本，确认没有加载系统默认的旧版库
• 禁止将DTS 8、新版Boost的库路径添加到系统全局ld.so.conf、账号全局环境配置（如.bashrc、.bash_profile）中，避免污染旧程序的运行环境

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