我有一个在armv7a Cortex-A9 CPU上编译的ELF。它运行良好没有问题，但当它移动到armv7a Cortex-A8 CPU时，文件默默退出如下：
casey @ arm：〜/ Unreal / System $ ./UCCLinux.bin.orig 卡西@臂：〜/虚幻/系统$
我构建了自己的UCCLinux.bin，它使用来自Cortex A9 CPU的未更改的共享对象，并且执行正常。这让我相信共享对象没有任何问题，而是与ELF本身有关。然而，差异ld --verbose / readelf只显示一个小差异。在我构建的版本上，它需要不同的依赖项。 ld-linux-armhf.so.3，其中不存在并替换为libm.so.6;我有。
工作系统上也有这个让我困惑的搜索路径： SEARCH_DIR（ “/ USR / armv7hl-SUSE-Linux的gnueabi / LIB”） armv7 * h * l，gnueabi上没有hf。我不确定这对USEntu的SuSE构建是否意味着什么，因为它们都是硬浮点，它可能只是语义。
两个系统上的ldd输出与原始文件匹配。除了那个依赖项的变化和一些相对较小的评论，可能来自不同发行版的不同编译器，我完全失去了。
我已经从我构建的文件和提供给我的文件中输出了输出。
○： http://pastebin.com/ef8Svn1Q
为： http://pastebin.com/04fyP5xt
我完全不知道为什么会发生这种情况，因为我尝试的所有其他小型测试程序都完美无瑕。出于某种原因，这只是一个文件。使用mtune = cortex-a8进行编译并没有改变任何东西，如果我们不得不分发一个“哦，顺便说一句，你必须编译自己的二进制文件甚至运行该东西”，这将是一个彻头彻尾的失败。另外，我怀疑这可能会产生一些潜在的问题。
相关{我的知识}编译器选项：
-march = armv7-a -mtune = cortex-a9 -mfloat-abi = hard -mfpu = vfpv3-d16
FPU匹配两个cpus，两者都是hardfloat armv7a。
有什么想法吗？
编辑：在Valgrind找到了一些新信息。
-1929--从/home/casey/Unreal/System/UCCLinux.bin.orig(0x8000)读取符号 --1929--从/lib/arm-linux-gnueabi/ld-2.15.so读取符号（0x4000000） --1929--考虑/lib/arm-linux-gnueabi/ld-2.15.so .. --1929-- .. CRC不匹配（计算c6793f6a需要66aab705） --1929--对象没有符号表
valgrind：启动时出现致命错误：函数重定向 valgrind：这个平台工具组合必须使用 valgrind：无法设置。重定向的细节是： valgrind：必须重定向的函数 valgrind：其名称与模式匹配：memcpy valgrind：在一个soname匹配的对象中：ld-linux.so.3 valgrind：处理过程中未找到 valgrind：来自具有soname的对象的符号：ld-linux.so.3
我的发行版既有hardfloat也有softfloat libs，尽管我认为它们是互斥的。