复制libstdc++库是否合规？GCC版本选择依据是什么？

1. 复制系统库并创建软链接的操作是否违规？ #

这种操作不算“违规”，但存在一定风险，具体分析：

• 从兼容性角度，你用的两个GCC版本（13.1.0和13.1.1）属于同大版本的小更新，libstdc++的API/ABI兼容性很高，临时替换不会出现严重问题。
• 潜在风险：
  • 若后续系统更新自带的libstdc++，可能导致/usr/local下的GCC编译的程序出现兼容性故障；
  • 重新编译/usr/local的GCC时，编译过程会自动生成新的libstdc++软链接，会覆盖你手动创建的链接，需要重新处理。
• 更稳妥的替代方案：
  • 临时设置环境变量LD_LIBRARY_PATH=/usr/lib64，让cmake优先使用系统库，不用修改文件；
  • 直接使用系统自带的GCC 13.1.1编译HandBrake，避免多版本GCC的依赖冲突；
  • 重新编译/usr/local的GCC 13.1.0时，指定使用系统的libstdc++（编译GCC时可通过配置参数控制）。

2. GCC各版本（9、10、11、12、13）的选择依据 #

选择GCC版本主要看以下几个维度：

• 项目官方要求：优先参考编译软件的官方文档，比如HandBrake 1.6.1如果明确指定了最低支持的GCC版本，必须满足该要求，否则可能出现编译失败或运行异常。
• 编程语言特性需求：
  • GCC 9完善了C17支持，开始引入部分C20特性；
  • GCC 11全面支持C++20核心特性；
  • GCC 13进一步优化了C++23特性支持，同时提升了编译速度和生成代码的性能。如果你的项目需要用到这些新特性，就选择对应版本。
• 系统生态兼容性：Fedora默认自带的GCC版本是和系统其他组件（如libc、libstdc++）深度适配的，用系统版本能避免大部分依赖冲突，稳定性最高。
• 第三方依赖链：如果编译的软件依赖的其他库是用特定GCC版本编译的，最好保持GCC版本一致，防止因libstdc++的ABI差异导致链接错误或运行时崩溃。
• 长期维护需求：如果是服务器等需要长期稳定运行的环境，优先选择LTS版本（比如GCC 11是LTS版本，有3年的bug修复支持）；桌面或开发环境可以选择最新稳定版，享受新特性和性能优化。

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