我重写产生了一些事情（共享/静态库，广口瓶，可执行文件，等）构建。问题出现了，是否有一种方法可以在不对结果软件进行完整的从上到下的测试的情况下验证结果在功能上是否相同。验证两个不同的构建的架构（一个在另一个的再写入）在功能上等同
但是，这被证明比我预料的要难得多。作为一个例子，我预计从相同的源（Sun Studio C++编译器）和命令行参数产生的两个对象的md5将具有相同的md5散列，但事实并非如此。我可以构建文件，重命名它，再次构建，并且它们具有不同的哈希值。
这一说...有没有办法做一个快速检查，以验证来自同一源代码树的独立的编译架构产生两个文件（例如，两个共享对象），在功能上等同？
编辑我很抱歉，我忽略提及这是一个调试版本...当调试标志不使用时，二进制文件是相同的，但他们已经默认使用调试标志多年他们的东西休息时删除调试标志（的我的部分原因重写的版本是采取特定的“功能”了构建，所以我们可以得到一些适当的测试准备）
我忘了这个问题;我正在重温，所以我可以给出我想出的答案。
objcopy可用于产生不同格式的一个新的二进制文件。这是我工作了几年，所以具体逃避我，但这里是我记得：
objcopy可以去除各种事情（调试信息，符号信息等），但即使剥离东西后，我仍然在物体之间看到不同的哈希值。
最后我发现我可以将它从ELF转换为其他格式。我最终将其转换为另一种格式（我认为我选择了SREC），该格式始终为在不同时间使用相同源/标记构建的对象提供相同的MD5。
我敢打赌，我可以用objcopy（或者另一个binutils工具）做到这一点，但它足以满足我们的担忧。
的Windows DLL有作为PE图像的一部分的链接时间戳（TimeDateStamp）。在linker options
来看，我没有看到一个选项，以抑制。所以重新链接一个DLL（或一个EXE）将总是产生一个不同的二进制文件。
你可以写一个工具来零这些时间戳（总是以固定从文件开始偏移），事后比较MD5s。但你可能会发现很多其他的差异。特别是，任何使用__DATE__或__TIME__ builtins的程序都会给你带来麻烦。
我们不得不努力工作以完成位相同的重建（使用GNU工具链）。这是可能的（至少在Linux上是开源工具），但并不容易（正如你发现的那样）。
我刚刚发现了更令人费解的事情。使用sun studio工具集，如果我构建时没有调试标志，目标文件（使用'-c'）仍然包含构建之间不同的符号，除非我传入'-s'来去除符号。在Linux中，即使这样也没有帮助（可能表明SS工具集中'-s'功能的Linux实现中存在一个错误） –
我在这里看到的令人费解的事情是调试标志的使用改变了与另一个使用相同调试标志构建的另一个输出相关的输出。因此，我敢说，你的设置不能安全地测试，因为一个输入（一组源文件）不会始终产生相同的输出。 {例如。你的构建过程并不是“功能性”的，因为一个输入会产生多个输出。} – Shark8