问题描述
我正在使用GNU工具链构建一个项目，在我将其链接之前，一切正常，链接器抱怨该链接丢失/找不到crti.o.这不是我的目标文件之一，它似乎与libc有关，但我不明白为什么它需要这个crti.o，不使用库文件，例如libc.a?
I'm building a project using a GNU tool chain and everything works fine until I get to linking it, where the linker complains that it is missing/can't find crti.o. This is not one of my object files, it seems to be related to libc but I can't understand why it would need this crti.o, wouldn't it use a library file, e.g. libc.a?
我正在为arm平台进行交叉编译.我的文件在工具链中，但是如何使链接器包含它?
I'm cross compiling for the arm platform. I have the file in the toolchain, but how do I get the linker to include it?
crti.o在库"搜索路径之一上，但是它应该在库路径上查找.o文件吗?
crti.o is on one of the 'libraries' search path, but should it look for .o file on the library path?
gcc和ld的搜索路径是否相同?
Is the search path the same for gcc and ld?
推荐答案
crti.o是引导程序库，通常很小.它通常静态链接到您的二进制文件中.应该在/usr/lib中找到.
crti.o is the bootstrap library, generally quite small. It's usually statically linked into your binary. It should be found in /usr/lib.
如果您正在运行二进制发行版，它们倾向于将所有开发人员的资料放入-dev软件包(例如libc6-dev)中，因为不需要运行已编译的程序，只需构建它们即可.
If you're running a binary distribution they tend to put all the developer stuff into -dev packages (e.g. libc6-dev) as it's not needed to run compiled programs, just to build them.
您不是交叉编译的吗?
You're not cross-compiling are you?
如果您要交叉编译，通常是gcc的搜索路径与crti.o所在位置不匹配的问题.它应该在工具链建立时就已构建.首先要检查的是gcc -print-search-dirs，然后查看crti.o是否在这些路径中.
If you're cross-compiling it's usually a problem with gcc's search path not matching where your crti.o is. It should have been built when the toolchain was. The first thing to check is gcc -print-search-dirs and see if crti.o is in any of those paths.
链接实际上是由ld完成的，但是它的路径是由gcc传递给它的.找出最新情况的最快方法是编译helloworld.c程序并跟踪它，以查看将什么传递给ld并查看正在发生的情况.
The linking is actually done by ld but it has its paths passed down to it by gcc. Probably the quickest way to find out what's going on is compile a helloworld.c program and strace it to see what is getting passed to ld and see what's going on.
strace -v -o log -f -e trace=open,fork,execve gcc hello.c -o test
打开日志文件并搜索crti.o，您会看到我的非交叉编译器:
Open the log file and search for crti.o, as you can see my non-cross compiler:
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感到困惑，您想看看它打开的路径是从哪里来的...
If you see a bunch of attempts to open(...crti.o) = -1 ENOENT, ld is getting confused and you want to see where the path it's opening came from...
这篇关于crti.o文件丢失的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！