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

如果您的代码崩溃(我假设您得到了一个sigsegv),那么似乎有一个bug。这很可能是某种未定义的行为,如使用悬空指针或在缓冲区边界上写入。

未定义行为的不幸之处在于 也许 在一些机器上工作。我想你正在经历这样一件事。尝试查找错误,您就会知道发生了什么:-)

我认为我们需要更多的细节:

1. testapp是否链接到库?

2. 图书馆是静态的还是动态的?

3. 库是否位于库搜索路径中,或者是否已将其目录添加到ld.so.conf?

4. 您是否遵循库和testapp的任何安装过程?

5. 这两个库和testapps是逐位兼容的吗?你认为他们会这样吗?

6. 您是否以与同事相同的用户身份运行,并且具有相同的环境和权限?

明显地 ,有些东西不一样。

你没有强调这一点,所以我想比努蒂尔斯是不同的。这是用于构建二进制文件的工具集。它包括ld、as和objdump。

对于目标体系结构,交叉编译器需要自己的一组binutil。但是,与GCC不同,我不相信binutils工具会执行双引导构建和验证步骤,因此可能是由于与原始x86_64构建环境的某些差异导致了它们。

我会再次尝试使用ARM交叉编译器为ARM构建binutils包。看看这是否有区别。

我在x86 Gentoo stage1的常规安装中也看到了这一点:在安装和更新引导系统和编译器之后,最好建议Gentoo用户重建系统 再一次 使用更新的工具。

你的目标(测试机器)是什么?

因此,编译器实际上可能有所不同。

我认识一个在大学里有类似经历的人。基本上,在一个由相同机器组成的实验室里,他的项目在开发箱上运行,但在开发箱上崩溃得很厉害。这是两台相同的机器,运行相同版本的操作系统。

它归结为某个未初始化的指针。

他有这样的代码:

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

因为p是在堆上分配的类的成员,所以它的值实际上是随机的,有时实际上是空的,这使得它可以正常工作。。。问题是 有时 等等 在机器上,p的内存在程序启动时为空,但在prof的盒子上则不是。修复程序当然是正确初始化p tp NULL,一切正常。

你可能正在经历类似的事情。或者某种类型的 这是一种花哨的说法,“它可能会,也可能不会像预期的那样,因为任何原因或根本没有原因”

作为一种冒险,我会寻找未初始化的变量。