这是设置：
我的同事有一台带有 gcc 4.3.3 交叉编译器（来自 buildroot）的 Fedora x64_86 机器。我有一台具有相同交叉编译器的 Ubuntu 9.04 x64_86 机器。
我的同事构建了一个可在测试机器上运行的库 + 测试应用程序，我编译了相同的库和 testapp，但它在同一台测试机器上崩溃了。
据我所知，gcc 是针对 buildroot 编译的 ucLibc 构建的，因此，相同的代码，相同的编译器。什么样的主机差异会影响交叉编译？
任何见解表示赞赏。
更新：为了澄清，编译器是相同的。库和 testapp 的源代码是相同的。唯一的区别是testapp + lib已经在不同的机器上编译过..
如果您的代码崩溃（我假设您获得了 sigsegv），则似乎存在错误。这很可能是某种未定义的行为，例如使用悬空指针或写入缓冲区边界。
未定义行为的不幸之处在于，它可能在某些机器上工作。我想你在这里遇到了这样的事件。尝试找到错误，您就会知道会发生什么:-)
它以什么方式崩溃？你能更具体一点，提供输出、返回码等...你试过插入一些有用的 printf() 吗？
而且，我认为我们需要更多细节：
testapp 是否链接到库？
库是静态的还是动态的？
该库是否在库搜索路径中，或者您是否已将其目录添加到 ld.so.conf？
您是否遵循库和 testapp 的任何安装程序？
这两个库和 testapps 是否逐位兼容？你希望他们是吗？
您是否以与同事相同的用户身份运行，具有相同的环境和权限？
显然，有些东西是不一样的。
尝试使用 objdump 及其许多选项，尤其是 -d，来确定有什么不同。
你没有说明这一点，所以我猜 binutils 是不同的。那是用于构建二进制文件的工具集。它包括 ld、as 和 objdump。
交叉编译器需要他们自己的一套用于目标架构的 binutils。但是，与 GCC 不同，我不相信 binutils 工具会执行双重引导构建和验证步骤，因此可能与原始 x86_64 构建环境存在一些差异。
我会尝试使用 ARM 交叉编译器再次为 ARM 构建 binutils 包。看看这是否有所作为。
这也是我在常规 x86 Gentoo stage1 安装中看到的：在安装和更新引导系统和编译器之后，强烈建议 Gentoo 用户使用更新的工具再次重建系统。
你的目标是什么拱门（测试机器）？
您是否使用发行版提供的编译器？他们通常有相当多的补丁集应用于 gcc，例如在 gentoo 上大约有 20 个补丁，fedora 和 ubuntu 不会有那么不同。不过，并非所有补丁都是 100% 好的 :-( 所以编译器实际上可能会有所不同。
您可能会在您的发行版中寻找“香草”版本的 gcc，也许它可以解决问题。
我认识一个在大学里有类似经历的人。基本上，在一个相同机器的实验室里，他的项目在他的开发箱上运行，但在教授箱上可怕地崩溃了。这是两台机器，它们是相同的架构，运行相同版本的操作系统。
它归结为某处未初始化的指针。
他的代码看起来像：
if(p == NULL) {
p = f();
}
由于 p 是在堆上分配的类的成员，它的值实际上是随机的，有时实际上是 NULL，使事情正常......问题是有时在某些机器上，p 的内存是 NULL在程序启动时，但在教授的盒子上，它不是。修复当然是正确初始化 p tp NULL 并且一切都很好。
你可能正在经历这样的事情。或者某种类型的未定义行为，这是一种奇特的说法，“它可能会也可能不会因为任何原因或根本没有原因而按预期工作”
作为黑暗中的刺，我会寻找未初始化的变量。确保为所有局部和全局变量赋值。仔细检查构造函数是否具有所有数据成员的初始化程序。