Object 验证两个不同的构建体系结构（一个是另一个的重写）在功能上是等效的

我正在编写一个生成许多东西（共享/静态库、JAR、可执行文件等）的构建。问题出现了，是否有一种方法可以验证结果在功能上是等效的，而无需对生成的软件进行完整的自上而下测试

然而，事实证明，这比我预期的要困难得多

作为一个例子，我预期从同一个源（SunStudioC++编译器）生成的两个对象的MD5和命令行参数将具有相同的MD5哈希值，但情况并非如此。我可以构建文件，重命名它，再次构建，它们有不同的散列

话虽如此。。。是否有一种快速检查的方法来验证由同一源代码树的独立构建体系结构（例如，两个共享对象）生成的两个文件在功能上是等效的

---

编辑对不起，我忘了提到这是一个调试版本。。。当不使用调试标志时，二进制文件是相同的，但是默认情况下它们已经使用调试标志很多年了，当您删除调试标志时，它们的内容就会中断（我编写构建的部分原因是为了从构建中删除特定的“功能”，以便我们能够进行一些适当的测试）

Windows DLL有一个链接时间戳（）作为PE映像的一部分

看看，我看不出有什么办法可以抑制它。因此，重新链接DLL（或EXE）将始终生成不同的二进制文件

您可以编写一个工具，将这些时间戳归零（始终在与文件开始的固定偏移量处），然后比较MD5。但是你也可能会发现很多其他的不同之处。特别是，任何使用

\uuuu日期\uuuu

或

\uuu时间\uuuu

内置项的程序都会给您带来麻烦

---

为了实现完全相同的重建（使用GNU工具链），我们不得不非常努力地工作。这是可能的（至少对于Linux上的开源工具而言），但并不容易（正如您所发现的那样）。

我忘记了这个问题；我正在重访，以便能给出我想出的答案

可用于生成不同格式的新二进制文件。我已经有几年没有做过这件事了，所以细节我想不起来，但我记得：

objcopy

可以剥离各种内容（调试信息、符号信息等），但即使剥离了这些内容，我仍然可以看到对象之间存在不同的散列

最后我发现我可以将它从ELF转换成其他格式。我最终将其转储到另一种格式（我想我选择了SREC），该格式始终为在不同时间使用相同源/标志构建的对象提供相同的MD5

---

我打赌我可以用

objcopy

（或者另一个

binutils

工具）做得更好，但这足以满足我们的担忧。

我在这里看到的令人困惑的事情是，调试标志的使用改变了与另一个使用相同调试标志构建的输出相关的输出。因此，我冒昧地说，您的设置无法安全地进行测试，因为一个输入（一组源文件）不会始终产生相同的输出。{例如，您的构建过程没有“功能性”，因为一个输入会产生多个输出。}我刚刚发现了更令人费解的东西。使用sun studio工具集，如果生成时没有调试标志，则对象文件（使用

-c

）仍包含不同生成的符号，除非传入

-s

以去除符号。在Linux中，即使这样也无济于事（可能表明SS工具集中

-s

功能的Linux实现中存在缺陷）