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

Question

一段时间以来，我一直在尝试为嵌入式linux (2.6)交叉编译jamvm (包括GNU类路径)，但我陷入了一个棘手的境地。

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

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

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

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

简单地说，我需要以一种不会抱怨glibc2.4或任何其他不受嵌入式系统支持的库的方式交叉编译jamvm (假设我知道适合我的体系结构的正确工具链)。

我真的很感激在这个问题上的任何帮助。如果我的推理不正确，我也会对这个主题有所了解。

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

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

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

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

如果这不是您要问的问题，很抱歉。