交叉编译 Makefile：处理测试程序答案

【问题标题】：Cross-compiling Makefile: dealing with test programs交叉编译 Makefile：处理测试程序
【发布时间】：2011-03-31 15:03:09
【问题描述】：

我正在尝试将多个库从 OSX 交叉编译到 iOS。我已经成功交叉编译了 libjpeg 和 libogg。

但我无法编译 libvorbis，因为configure 坚持要创建和运行一个小型测试程序。这显然失败了，因为它创建了一个 armv7 二进制文件，无法运行它，然后将其解释为缺少 ogg 库。

您通常如何处理此类问题？我很想破解配置脚本来解决这些问题，但是由于这种故障，某些功能可能会被禁用。我也在考虑让configure 生成一个原生的 Makefile，然后将其转换为使用 iOS 工具链，但这似乎太容易出错了。

有什么建议吗？

【问题讨论】：

正在检查 oggpackB_read... 没有配置：错误：需要更新的 libogg 版本（1.1 或更高版本）
config.log 说 ld: warning: directory '${exec_prefix}/lib' following -L not found ld: warning: in /usr/local/lib/libogg.dylib, file is built for i386 不是被链接的架构（armv7）它试图与 /usr/local/lib 而不是 /usr/local/ios/lib 链接，尽管 AFAIK 我正确设置了每个标志：S

标签： iphone gcc makefile cross-compiling configure

【解决方案1】：

如果您要交叉编译任何比 libc (glibc) 具有更多依赖项的东西，它会变得更加复杂。您需要已经交叉编译了所有依赖项。并且交叉编译器工具链和所有帮助程序构建程序和脚本都需要知道如何找到这些依赖项（交叉编译的库和头文件）。

您需要已经交叉编译了 libogg（及其依赖项）并将它们安装到交叉编译根目录中。构建系统中的头文件和库不能用于主机 (arm7) 系统。它们必须分开存放。

此外，如果您想拥有共享对象库 (*.so) 而不仅仅是静态库，那么就会出现一系列全新的复杂情况。例如，虽然交叉编译器工具链包含交叉编译的 libc 作为工具链的一部分，但您仍然需要用于主机系统的 libc。作为工具链一部分的 libc 可以用于此目的，但它的结构方式与主机系统上的不同。有时人们会复制并重新排列文件，但通常人们只是为根目录编译和安装新的 glibc。

无论如何，要说的是，您看到的两个错误是因为配置脚本无法找到交叉编译的 libogg 库。如果您还没有，您需要交叉编译 libogg（和依赖项）并将它们安装到您的目标根目录中。然后你需要告诉配置脚本你的交叉编译头文件（是的，头文件是特定于架构的）和库在你的目标根目录中。通常使用 CFLAGS、LDFLAGS、CXXFLAGS 等（不是 --prefix），但您可能还需要设置其他环境变量以影响 pkg-config 等内容。构建每个依赖项后，您需要获取makefile 将依赖项安装到根目录。通常这是通过make DESTDIR=[root] install 完成的，但一些makefile 有自己的机制（或没有适当的替代安装机制）。

您可能还需要覆盖某些编写不佳且没有良好交叉编译默认值的配置检查（使用环境变量）。这些变量通常以 ac_cv_* 开头

所以基本过程是为您需要的包执行此操作（按依赖顺序）：

export CFLAGS=-I[root]/usr/include LDFLAGS=-L[root]/usr/lib CXXFLAGS=-I[root]/usr/include
export ac_cv_[test1]=[yes|no] ac_cv_[test2]=[yes|no] ...
./configure --host=[arm7-blah-blah]
make
make DESTDIR=[root] install

祝你好运。一旦您对标准交叉编译感到满意，那么您将准备好接受真正的黑艺术Canadian cross ;-)

【讨论】：

感谢您提供的所有信息 :) 事实上，很长一段时间以来，我曾经使用 mingw 环境从 Linux 交叉编译 Windows 二进制文件，但我从未遇到过这个问题。

【解决方案2】：

我终于明白了。我通过显式使其与 ogg (LDFLAGS="/usr/local/ios/lib/libogg-armv7.a" ./configure ...) 链接来欺骗 configure，然后从生成的 makefile 中删除对库的显式引用。

【讨论】：

三件事：首先，您滥用 LDFLAGS 附加到您的链接行（即指定完整路径并不是真正的 LD 标志）。更正确的是 LDFLAGS="-L/usr/local/ios/lib"。其次，您的解决方案只是我建议的一个更具体的案例（即，一旦您尝试构建其他东西就会中断）。 IE。 /usr/local/ios 是我提到的目标根目录。第三，如果该信息对您有用但不是一个足够的答案，您可以考虑投票支持我的答案。谢谢。
@kanaka，感谢您的 cmets；我刚刚赞成你的回答。至于问题本身，传递 -L 是我尝试的第一件事，但它没有任何效果 - configure 一直试图链接到系统范围的 ogg（可能是因为 dylib 优先于静态库，我不知道）。我知道这是一种 hack，但在我必须交叉编译的所有库中，只有这个有问题，而且我无意或没有时间深入研究配置内部结构。
是的，这很合理。 autoconf（尤其是 libtool）在处理库路径解析的方式上可能相当不透明。如果您希望构建额外的库和/或应用程序，其依赖关系不那么简单，您可能需要跟踪问题。如果它只是一次性的，那就做任何有效的事情。