28

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

我正在为 arm 平台进行交叉编译。我在工具链中有文件，但是如何让链接器包含它？

crti.o位于“库”搜索路径之一，但它应该.o在库路径上查找文件吗？

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

4

8 回答 8

28

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

如果您正在运行二进制发行版，他们倾向于将所有开发人员的东西放入 -dev 包（例如 libc6-dev）中，因为它不需要运行已编译的程序，只是为了构建它们。

你不会交叉编译吧？

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

链接实际上是由 ld 完成的，但它的路径由 gcc 传递给它。找出正在发生的事情的最快方法可能是编译一个 helloworld.c 程序并对其进行 strace 以查看传递给 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就会感到困惑，你想看看它打开的路径来自哪里......

于 2008-09-18T10:54:09.183 回答
6

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

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

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

于 2015-05-08T06:52:14.940 回答
6

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

$ find /usr/ -name crti*

我什么也没找到，所以我安装了开发人员包：

sudo apt-get install libc6-dev

如果你发现一些库在这里阅读

于 2016-10-19T11:19:59.067 回答
1

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

于 2008-09-18T14:41:26.843 回答
1

我有一个错误设置的交叉编译器的类似问题。我像这样绕过它：

/home/rob/compiler/usr/bin/arm-linux-gcc --sysroot=/home/rob/compiler hello.c

这假定 /lib、/usr/include 等存在于 sysroot 选项指向的位置。这可能不是应该做的事情，但是当我需要编译一个简单的 C 文件时，它让我摆脱了麻烦。

于 2011-10-20T14:39:45.133 回答
1

如果要交叉编译，请在 LDFLAGS 中添加 sysroot 选项

export LDFLAGS=""--sysroot=${SDKTARGETSYSROOT}" -L${SDKTARGETSYSROOT}/lib -L${SDKTARGETSYSROOT}/usr/lib -L${SDKTARGETSYSROOT}/usr/lib/arm-poky-linux-gnueabi/5.3.0"
于 2019-12-09T08:03:37.400 回答
0

我在默认的 Ubuntu 8.04 安装中遇到了同样的问题。我必须手动获取 libc 开发人员头文件/文件才能正常工作。

于 2008-09-18T10:54:12.303 回答
0

这为我解决了（为 ARM 交叉编译 pjsip）：

export LDFLAGS='--sysroot=/home/me/<path-to-my-sysroot-parent>/sysroot'
于 2014-09-17T21:37:51.100 回答