crti.o文件丢失

Ric*_*ard 24 linker makefile

我正在使用GNU工具链构建一个项目,一切正常,直到我链接它,链接器抱怨它丢失/无法找到crti.o.这不是我的目标文件之一,它似乎与libc有关但我无法理解为什么它需要这个crti.o,它不会使用库文件,例如libc.a

我正在为手臂平台进行交叉编译.我在工具链中有该文件,但如何让链接器包含它?

crti.o在一个'库'搜索路径上,但是它应该.o在库路径上查找文件吗?

在搜索路径同样为gccld

sts*_*uad 25

crti.o是bootstrap库,通常很小.它通常静态链接到您的二进制文件.它应该在/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
Run Code Online (Sandbox Code Playgroud)

打开日志文件并搜索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
Run Code Online (Sandbox Code Playgroud)

如果你看到一堆尝试open(...crti.o) = -1 ENOENT,ld就会感到困惑,你想看看它开启的路径来自哪里......


chr*_*ris 6

我在交叉编译时遇到了同样的问题。crti.o 在< sysroot >/usr/lib64 中,但链接器找不到它。

事实证明,创建一个空目录<sysroot>/usr/lib解决了这个问题。似乎链接器会首先搜索路径<sysroot>/usr/lib,并且仅当它存在时才会考虑<sysroot>/usr/lib64

这是链接器中的错误吗?或者这种行为是否记录在某处?

  • 这对我有用。我不敢想象你必须经历多少混乱才能发现这一点。不知道这是一个错误还是什么 - 但也许值得在 GNU ld bugzilla 或邮件列表或其他东西上讨论。 (2认同)

Eug*_*kov 6

就我而言Linux Mint 18.0/Ubuntu 16.04,我根本没有crti.o

$ find /usr/ -name crti*
Run Code Online (Sandbox Code Playgroud)

我什么也没找到,所以我安装了开发包:

sudo apt-get install libc6-dev
Run Code Online (Sandbox Code Playgroud)

如果您找到一些库,请阅读此处