Ubuntu 18.04下定义_GNU_SOURCE时Coverity Scan编译<stdlib.h>失败如何解决？

我之前也碰到过一模一样的问题，Coverity 2017.07版本和Ubuntu 18.04的glibc头文件在处理_GNU_SOURCE宏时存在兼容性bug，导致只要定义了这个宏并包含<stdlib.h>就会编译失败。下面是几个亲测有效的解决办法：

方法1：升级Coverity到兼容版本 #

Coverity 2017.07发布于Ubuntu 18.04正式版之前，对新版本glibc的头文件特性支持不足。你可以去官方下载至少2018.07及以后的版本（后续版本修复了不少系统兼容性问题），替换掉当前的/opt/cov-analysis目录后，再重新运行编译命令：

/opt/cov-analysis-new/bin/cov-build --dir cov-int gcc -D_GNU_SOURCE=1 -o main main.c

升级后基本就能正常处理_GNU_SOURCE宏的场景了，这也是最彻底的解决方案。

方法2：禁用_FORTIFY_SOURCE宏 #

Ubuntu 18.04的glibc在定义_GNU_SOURCE时会自动启用_FORTIFY_SOURCE=2，而旧版Coverity对这个强化编译选项的处理存在问题。你可以在编译时手动取消这个宏：

cov-build --dir cov-int gcc -D_GNU_SOURCE=1 -U_FORTIFY_SOURCE -o main main.c

这个方法不需要升级Coverity，临时解决问题很方便，亲测可以让编译单元100%成功提交。

方法3：关闭Coverity的编译器重定向 #

如果上面两种方法都不行，可以尝试让Coverity直接调用系统原生gcc，不通过它的重定向层：

cov-build --dir cov-int --no-redirect-compiler gcc -D_GNU_SOURCE=1 -o main main.c

不过这个选项可能会影响Coverity对代码的扫描深度，建议只作为临时应急方案使用。

你可以根据自己的实际情况选择其中一种方法，一般优先推荐升级Coverity版本。

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