我正在使用GNU工具链构建一个项目，在我将其链接之前，一切正常，链接器抱怨它丢失/找不到crti.o。这不是我的目标文件之一，它似乎与libc有关，但是我不明白为什么它需要这个crti.o，而不使用库文件，例如libc.a？

我正在交叉编译手臂平台。我的文件在工具链中，但是如何使链接器包含它？

crti.o在'libraries'搜索路径之一上，但是它应该在库路径中查找.o文件吗？

gcc和ld的搜索路径是否相同？

解决方案

crti.o是引导程序库，通常很小。它通常静态链接到二进制文件中。它应该在/ usr / lib中找到。

如果我们正在运行二进制发行版，它们倾向于将所有开发人员的资料放入-dev软件包(例如libc6-dev)，因为不需要运行已编译的程序，只需构建它们。

我们不是交叉编译的吗？

如果我们要交叉编译，通常是gcc的搜索路径与crti.o所在位置不匹配的问题。它应该在工具链建立时就已构建。首先要检查的是gcc -print-search-dirs，看看crti.o是否在这些路径中。

链接实际上是由ld完成的，但是它的路径是由gcc传递给它的。找出正在发生的事情的最快方法是编译helloworld.c程序并跟踪它，以查看将什么传递给ld并查看正在发生的事情。

strace -v -o log -f -e trace=open,fork,execve gcc hello.c -o test

打开日志文件并搜索crti.o，因为我们可以看到我的非交叉编译器：

10616 execve("/usr/bin/ld", ["/usr/bin/ld", "--eh-frame-hdr", "-m", "elf_x86_64", "--hash-style=both", "-dynamic-linker", "/lib64/ld-linux-x86-64.so.2", "-o"
, "test", "/usr/lib/gcc/x86_64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."..., "-L/usr/lib/gcc/x86_64-linux-g
nu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/usr/lib/gcc/x86_64-linux-gnu/"..., "-L/lib/../lib", "-L/usr/lib/../lib", "-L/usr/lib/gcc/x86_64-linux-gnu
/"..., "/tmp/cc4rFJWD.o", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "-lc", "-lgcc", "--as-needed", "-lgcc_s", "--no-as-needed", "/usr/lib/gcc/x86_
64-linux-gnu/4."..., "/usr/lib/gcc/x86_64-linux-gnu/4."...],  "COLLECT_GCC=gcc", "COLLECT_GCC_OPTIONS=\'-o\' \'test\' "..., "COMPILER_PATH=/usr/lib/gcc/x86_6"..., "LIBRARY_PATH=/usr/lib/gcc/x86_64"..., "CO
LLECT_NO_DEMANGLE="]) = 0
10616 open("/etc/ld.so.cache", O_RDONLY) = 3
10616 open("/usr/lib/libbfd-2.18.0.20080103.so", O_RDONLY) = 3
10616 open("/lib/libc.so.6", O_RDONLY)  = 3
10616 open("test", O_RDWR|O_CREAT|O_TRUNC, 0666) = 3
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crt1.o", O_RDONLY) = 4
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/../../../../lib/crti.o", O_RDONLY) = 5
10616 open("/usr/lib/gcc/x86_64-linux-gnu/4.2.3/crtbegin.o", O_RDONLY) = 6
10616 open("/tmp/cc4rFJWD.o", O_RDONLY) = 7

如果我们看到一堆试图open(... crti.o)= -1 ENOENT的尝试，则ld变得很困惑，我们想看看它打开的路径是从哪里来的...

我在默认的Ubuntu 8.04安装上遇到了同样的问题。我必须手动获取libc开发人员标头/文件才能运行。

好的，我必须重新安装工具链，以便随后包括缺少的文件。似乎很奇怪，因为它应该在gcc路径上找到它。我猜的主要问题是我的计算机上有15个左右的crti.o文件，但没有指向正确的文件。从那以后仍然没有，但是现在可以了:-)感谢帮助:-)