GCOV 版本不匹配 - 预期 700e 得到 408R答案

【问题标题】：GCOV Version mismatch - expected 700e got 408RGCOV 版本不匹配 - 预期 700e 得到 408R
【发布时间】：2020-06-06 04:20:57
【问题描述】：

在一台装有 GCC 4.4.7/GCOV 4.4.7 的服务器上，我能够成功运行测试。但是，在具有 GCC 4.8.5/GCOV 4.8.5 的不同服务器上，运行测试会导致此错误：

profiling:/path/to/foo.gcda:Version mismatch - expected 700e got 408R

这是版本的输出：

$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

$ gcov --version
gcov (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)

搜索了这个错误，好像是gcc和gcov版本不匹配造成的，但是我的版本是一样的。

我们最近将此服务器上的 gcc 从 4.4.7 升级到了 4.8.5。这个问题似乎是升级引起的。

我应该提到我正在测试一个 Python C 扩展，我认为这与测试一个普通的 C 应用程序有点不同。

我执行以下操作：

export CFLAGS="--coverage"
python setup.py build_ext --inplace
python tests.py

在两台服务器上，第二个命令会适当地创建 .gcno 文件。

在 4.4.7 的服务器上，第三条命令将成功创建 .gcda 文件。但是 4.8.5 的服务器会打印该错误消息

【问题讨论】：

既然您说您最近升级了工具链，那么您的测试是否有可能针对部分或全部由旧工具链构建的对象运行？
@JohnBollinger python3的安装肯定是以前版本的gcc构建的-我应该重新安装吗？
@JohnBollinger 我用当前版本的 gcc 删除并重新安装了 python3，但没有运气。
除非 Python 解释器是被测试的代码——我不认为是这种情况——这不是我要说的。 Python 会考虑到这一点并不是不可能的，但我所说的是您正在构建和测试的扩展，它是使用用于覆盖分析的仪器构建的。请确保 that 是从其源代码干净地构建的。为此，请注意它可能依赖的任何静态库。
@JohnBollinger 明白了，谢谢。此 C 扩展所依赖的主要静态库尚未在此服务器上重建。我会在我们升级的另一台已经重建的服务器上试试这个，然后通知你。

【解决方案1】：

一个版本的 GCC 生成的覆盖率检测与其他版本的覆盖率检测不完全兼容，因此 GCC 对其进行了版本化。报告的错误消息似乎表明您正在使用工具链的一个版本对至少部分使用不同版本构建的工件和工具执行覆盖率分析。

要解决此问题，您应确保所有检测过的二进制文件（包括任何库）以及任何其他与覆盖范围相关的构建工件都是通过相同版本的工具链生成的。从被测组件的源代码进行完全干净的重建——包括任何检测库，无论是否属于同一构建——应该可以解决问题。但是，可能没有必要重新构建尚未用于覆盖测试的二进制文件。

【讨论】：