我一直试图为嵌入式Linux（2.6）交叉编译jamvm（包括GNU类路径），我陷入了一个微妙的地方。
我将尝试总结：经过很多错误后我终于为我的架构编译了包，但是虽然我在./configure中指定了--enable-static，当我尝试运行jamvm时它抱怨不找到GLIBC 2.4。问题是我有2.3.5版本并且为我的架构编译2.4目前不是一个选项（这将意味着开始一个全新的问题）。
我怀疑问题来自于使用与嵌入式目标支持的工具链不同的机器构建。
问题是我知道与我的CPU匹配的确切gcc，glibc，binutils和linux内核头文件，但问题是我不知道如何在交叉编译/构建中包含这些信息处理。
但是，假设我的机器使用不同的工具链会影响交叉编译，也许我错了。
简单来说，我需要交叉编译jamvm，它不会抱怨glibc 2.4或任何其他未被嵌入式系统支持的库（假设我知道我的架构的正确工具链）
对于这个问题我真的很感激。如果我的推理不正确，我也会对这个话题有所启发。
答案 0 :(得分：2)
我不确定我是否理解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依赖项（如果{{ 1}}是GLIBC v2.15中唯一的符号。
您可以在源代码中使用此指令选择要使用的posix_spawn版本，在实际使用该符号的单元（posix_spawn或.c文件）的开头：
.cpp很抱歉，如果这不是您要求的。