发现交叉编译中的大问题，jamvm

Question

我已经尝试了一段时间为嵌入式linux(2.6)交叉编译jamvm(包括GNU类路径)，我被困在一个微妙的地方。

我将尝试总结:在很多错误之后，我终于为我的体系结构编译了这个包，但是尽管我在。/configure中指定了——enable-static，当我试图运行jamvm时，它抱怨找不到GLIBC 2.4。问题是我有2.3.5版本，为我的体系结构编译2.4版本目前不是一个选择(这将意味着开始一个全新的问题)。

我怀疑问题来自于使用与嵌入式目标支持的工具链不同的机器构建。

事情是，我知道确切的gcc, glibc, binutils，和linux内核头匹配我的CPU，但问题是，我不知道如何在交叉编译/构建过程中合并这些信息。

然而，也许我错误地认为我的机器使用不同的工具链会影响交叉编译。

简单地说，我需要交叉编译jamvm，使它不会抱怨glibc 2.4或嵌入式系统不支持的任何其他库(假设我知道适合我的体系结构的正确工具链)

关于这个问题，我将非常感谢任何帮助。如果我的推理不正确，我也希望你能给我一些启发。

Answer 1

我不确定我100%理解你的问题，但也许试着建立一个符号列表，通过使用创建对GLIBC 2.4的依赖:

$ readelf -Ws <your_jamvm_executable_file> | grep @GLIBC_2.4

(如果找不到任何符号，请使用更宽松的grep搜索模式)

然后，检查违规符号是否在GLIBC中有其他版本，等于或低于GLIBC v2.3.5。我将以posix_spawn为例:

(1:517)$ readelf -Ws /lib/libc.so.6 | grep posix_spawn@
  1666: 000d8800    51 FUNC    GLOBAL DEFAULT   12 posix_spawn@@GLIBC_2.15
  1667: 00127760    51 FUNC    GLOBAL DEFAULT   12 posix_spawn@GLIBC_2.2

这意味着如果发现posix_spawn在GLIBC v2.15中被拉入，您的程序可以从GLIBC v2.2中重新编译为使用posix_spawn，删除GLIBC 2.15依赖项(如果posix_spawn是GLIBC v2.15中唯一的拉入符号)。

您可以通过在源代码中使用此指令来选择使用哪个posix_spawn版本，在实际使用符号的单元(.c或.cpp文件)的开头:

__asm__(".symver posix_spawn,posix_spawn@GLIBC_2.2");

对不起，如果这不是你想要的。