为什么在两台略有不同的机器上编译的库的行为略有不同？

Question

这是设置：

我的同事有一台带有GCC 4.3.3交叉编译器（来自BuildRoot）的Fedora X64_86机器。我有一个带有相同交叉编译器的Ubuntu 9.04 x64_86机器。

我的同事构建了一个在测试机上使用的库 +测试应用程序，我编译了同一库和TestApp，并且在同一台测试机上崩溃了。

据我所知，GCC反对构建的buildRoot编译UCLIBC，因此，相同的代码，相同的编译器。哪些主机机器差异会影响交叉编译？

任何洞察力都赞赏。

更新：为澄清，编译器是 完全相同的. 。库和testapp的源代码是 完全相同的. 。唯一的区别是TestApp + Lib已在不同的机器上编译。

Answer 1

如果您的代码崩溃（我假设您得到了SigSeGV），则似乎有一个错误。这很可能是某种不确定的行为，例如使用悬空的指针或在缓冲边界上写作。

不确定行为的不幸点是 可能 在某些机器上工作。我认为您在这里经历了这样的活动。尝试查找错误，您会知道会发生什么:-)

Answer 2

它以什么方式崩溃？您能否更具体，提供输出，返回代码等...您是否尝试插入一些有用的printf（）？

而且，我认为我们在这里需要更多细节：

1. TestApp是否链接到库？

2. 库是静态的还是动态的？

3. 库中的库是搜索路径中的库，还是将其目录添加到ld.so.conf中？

4. 您是否遵循图书馆和TestApp的任何安装过程？

5. 两个库和testapps是否兼容？您希望它们成为吗？

6. 您是否以与同事相同的环境和权限为同一用户？

Answer 3

明显地, ，某些东西并不相同。

尝试使用objdump及其许多选项，尤其是-D，以确定什么不同。

您没有提出意思，所以我要猜测Binutils就是不同的。那是用于构建二进制文件的一组工具。它包括LD，AS和Objdump。

跨编译器需要自己的一套目标架构。但是，与GCC不同，我不认为Binutils工具可以进行双hootstrap构建和验证步骤，因此与原始的X86_64构建环境有可能使其变成它们。

我将尝试使用手臂交叉副手再次构建双臂套件。看看这是否有所作为。

这是我在常规X86 Gentoo stage1中看到的东西：在安装和更新的Bootstrap系统和编译器后，Gentoo用户被很好地推荐了重建系统 再次 使用更新的工具。

Answer 4

您的目标是什么拱门（测试机）？

您是否正在使用提供的编译器？他们通常在GCC上有大量的补丁，例如在Gentoo上，大约有20个补丁，Fedora和Ubuntu不会那么不同。但是，并非所有的补丁都100％罚款：--(因此编译器实际上可能有所不同。

您可能会在发行版中寻找GCC的“香草”版本，也许可以解决问题。

Answer 5

我认识一个在大学里经历过类似经历的人。基本上，在相同机器的实验室中，他的项目在他的开发盒上工作，但在教授盒子上崩溃了。这是两台机器，它们是相同的拱门，运行了相同的OS版本。

它归结为某个地方的一个非初始化的指针。

他的代码看起来像：

if(p == NULL) {
    p = f();
}

由于P是分配在堆上的班级的成员，因此其价值有效地随机，偶尔是无效的，使事情正常工作……问题是问题是 有时 然后 一些 机器，P的记忆在程序启动中是无效的，但是在教授的框中，事实并非如此。当然，修复程序是正确初始化p tp null的，一切都很好。

您可能正在经历这样的事情。或某种类型的 不确定的行为 这是一种奇特的说法：“它可能会或根本没有理由可能无法按预期工作”

Answer 6

作为黑暗中的刺伤，我会寻找非专业化的变量。确保将所有本地变量和全局变量分配为一个值。仔细检查构造函数是否具有所有数据成员的初始化器。