【问题标题】:Is it reasonable to expect two shared libraries built on two identical platforms?期望两个共享库构建在两个相同的平台上是否合理?
【发布时间】:2013-01-07 04:03:15
【问题描述】:

如果我构建相同的源代码,链接到相同版本的相同库,使用相同的工具链(相同的编译器,链接器等,GCC 4.4),使用相同版本的相同操作系统,(Centos 5 Linux 就我而言)但在两台不同的机器上;

假设生成的二进制文件应该相同是否合理?

这背后的背景是我的代码具有“未定义的行为”,它在一种配置上“有效”,但在另一种配置上无效,显而易见的答案是解决这个问题,但我想知道我的假设是否应该生成二进制文件相同的是正确的。

我注意到大小有几百字节的差异,使用“nm”命令显示的符号位置略有不同,即使符号相同。

【问题讨论】:

  • 您拥有共享库所依赖的所有其他组件,例如 glibc 是最明显的?
  • 如果你在同一台机器上以相同的方式但在不同的时间构建相同的源代码,结果是否相同?
  • 简短的回答实际上是“如果一切都完全相同”,那么您应该得到相同的结果[除了“日期”和“内部版本号”以及类似信息'在编译时提供- time' 包含在二进制文件中 - 但这只会影响该信息本身]。
  • 但是,我怀疑您的系统之间有些不同 - 编译器的版本不完全相同,或者 glibc 不一样[或者不是用相同的编译器构建的,等等].

标签: c++ linux toolchain gnu-toolchain


【解决方案1】:

通常我希望日期和/或元数据即使在同一主机上的构建之间也会略有不同。

您还忽略了提及编译器标志(例如优化和命令行中的#defines)。

然而,我最初怀疑文件的大小应该相同,这导致我们得出结论,something 在两个系统中相同。最有可能的候选者是系统头文件(操作系统安装中的一个根级功能可能会导致这些文件的视图完全不同)和任何依赖库。

您可以通过使用g++ -E 或类似方法进行预处理来检查标头是否相同。您还可以按照库路径并确认链接到的文件在每个系统上都是相同的。

【讨论】:

  • 通常目标文件包含时间戳,以及标识操作系统和编译器的字符串。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-07-29
  • 2016-06-20
  • 2019-04-02
  • 1970-01-01
相关资源
最近更新 更多