我正在尝试使用Tizen工具集构建zlib。作为构建过程的一部分，源文件应该被编译为arm-linux-gnu-eabi-gcc -c的对象，然后合并到libtool的归档中，但libtool失败并抱怨每个传递给.o的{{1}}个文件。
经过检查，我发现is not an object file (not allowed in a library)正在生成ELF文件而不是目标文件，这是我以前从未见过的。当我将arm-linux-gnu-eabi-gcc -c传递给编译器时，我可以看到链接器没有被调用。那么为什么选择ELF格式？
然后我尝试调用-c -v后跟arm-linux-gnu-eabi-gcc -S，发现汇编程序本身正在生成ELF文件。
以下是一个例子：
arm-linux-gnu-eabi-asTizen工具集包括四个编译器（{i386，arm}和{4.6,4.9}）。这四种行为都是一样的。
至少这个% echo "int main(void) { return 0; }" > main.c
% arm-linux-gnueabi-gcc main.c -S -o main.s
% arm-linux-gnueabi-as main.s -o main.o
% file main.o
main.o: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped
是一致的，因为我可以传递一些arm-linux-gnueabi-gcc个ELF文件，它似乎正确地链接它们。但是我仍然需要能够生成真实的目标文件，以便将它们归档到具有.o的静态库中。有什么建议吗？
答案 0 :(得分：1)
生成ELF文件而不是目标文件
你非常困惑：ELF和目标文件不是独占的，而在Linux 所有目标文件都是ELF。换句话说，这是按预期工作的。
ELF个文件可以有不同的类型：ET_REL（可重定位的对象文件），ET_DYN（共享库）和ET_EXEC（可执行文件）
我仍然需要能够生成真实对象文件，以便可以使用libtool将它们存档到静态库中
问题可能是libtool无法识别非原生ELF .o个文件，因为它可以放入存档库中。
通常，libtool几乎总是解决问题的错误的解决方案，无论问题是什么。它的stated goal是“隐藏在一致的可移植接口背后使用共享库的复杂性”。根据我的经验，它无法在所有平台上实现这一目标。
当然，如果只是想要将一堆.o文件放入存档库中，那么正确的方法就是使用*-linux-gnueabi-ar而不应该没有问题