GCC 4.9升8.x报错'min' was not declared in this scope咨询

• 系统从Debian Jessie升级至Buster后，已投入使用超20年、跨Windows/Linux多平台共用的共享代码库在Linux环境下构建失败，出现版本兼容性断裂问题
• 构建报错的模块为.cpp格式文件，需求为找到对应编译开关，让编译器保持旧版本行为，正常识别min()函数
• 约束条件：
  • 不能在主头文件中添加宏定义：代码库体量极大，修改公共头文件会触发所有平台的全量重编译，成本不可接受
  • 不能强制代码统一使用std::min：部分部署环境仍在使用版本极旧的编译器，不支持该标准库写法
• 稳定复现条件：代码中引入#include <stdlib.h>时必然触发该构建错误

问题根源是Debian Buster搭载的glibc版本从Jessie时代的2.19升级到了2.28，同时系统默认GCC版本从4.9升级到8.x，默认编译规则收紧，不再默认暴露全局命名空间下的min()/max()定义，不需要修改代码或公共头文件，通过以下任意一种编译参数调整即可解决：

• 方案一：调整编译标准为GNU扩展模式
  如果你当前编译该模块时使用的是严格C标准参数（比如-std=c++98、-std=c++11这类不带gnu前缀的标准配置），直接替换为对应版本的GNU扩展标准即可，比如原来使用C98标准就换成-std=gnu++98。该参数是纯编译开关，不需要修改任何代码，开启后编译器会完全兼容旧版本Debian下的头文件解析逻辑，全局min()函数会正常可见，和升级前行为完全一致。
• 方案二：仅对出错的编译单元添加功能宏
  如果不方便调整全局编译标准，只需要给构建失败的单个.cpp文件的编译命令加上-D_GNU_SOURCE参数即可。该宏通过编译命令行传入，不需要修改任何公共头文件，仅对当前编译的单个文件生效，不会触发其他模块的重编译，也不会影响Windows等其他平台的构建逻辑。你可以在构建脚本中加环境判断，仅在Linux新版本glibc环境下给对应文件追加该参数，旧版本编译器、其他平台的构建流程完全不受影响，也不需要改动现有代码的min()调用写法。

注意：不要把_GNU_SOURCE宏加到公共头文件中，仅通过编译参数给需要的单个文件追加即可，完全满足你提出的两个约束条件。

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