为什么 GCC 交叉编译不构建“crti.o”?
在尝试为arm构建gcc 4.xx交叉编译器时,我陷入了$BUILD_DIR/gcc
子目录中缺少crti.o
文件的困境。
顶层 Makefile
上的 strace
显示编译后的 xgcc
正在使用 调用交叉链接器
作为参数。我假设如果调用交叉链接ld
>“crti.o”ld
,则不需要本机/usr/lib/crti.o
。
我可以看到,在 gcc 源代码树中,有许多 crti 对象的潜在源(包括 $SRC_DIR/gcc/config/arm/crti.asm)。
如何配置 gcc 构建以确保构建此文件(或从 ld
命令中省略)?
这是我的配置行:
/x-tools/build/gcc-4.5.0$ ../../src/gcc-4.5.0/configure --target=arm-linux --prefix=/opt/arm-tools --disable-threads --enable-languages=c
In an attempt to build a gcc 4.x.x cross compiler for arm, I'm stuck at a missing crti.o
file in the $BUILD_DIR/gcc
subdirectory.
An strace
on the top level Makefile
shows that the compiled xgcc
is calling the cross-linker ld
with "crti.o"
as an argument. I'm assuming that if the cross linking ld
is being called, the native /usr/lib/crti.o
is not what is needed.
I can see that in the gcc source tree there is a number of potential sources for a crti object (including $SRC_DIR/gcc/config/arm/crti.asm
).
How can I configure the gcc build to insure this file is built (or omitted from the ld
command)?
Here is my configure line:
/x-tools/build/gcc-4.5.0$ ../../src/gcc-4.5.0/configure --target=arm-linux --prefix=/opt/arm-tools --disable-threads --enable-languages=c
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
真正的答案是,如果要构建一个arm-elf目标,它应该编译
crti.o
。在构建 arm-linux 目标时,gcc 人们合理地假设 glibc 之前已编译并且它将提供crti.h 文件。 o 启动。完全合理,如果您要升级。
构建新的根文件系统是另一回事,这是一个自相矛盾的故事(哪个先出现:glibc 或gcc?)。一种方法(已认可,但我尚未成功)是构建一个独立的 gcc(比如arm-elf\static),然后构建 glibc ,然后再次gcc。
似乎有些人已经通过 modfiying
gcc\config\arm\t-linux
解决了 arm-linux 目标中缺少的crti.o
。与其依赖不存在的 glibc,而是使用 arm-elf 提供的crti.o
版本。可以在此处找到示例。The real answer is that it should compile
crti.o
if one was to build an arm-elf target. In building an arm-linux target, the gcc people reasonably assume that glibc has been compiled previously and it will provide thecrti.o
startup. Perfectly reasonable, if you're upgrading.Building a new root file system is another story, a paradoxical one at that (which comes first: glibc or gcc?). An approach (endorsed, but I've not yet succeeded with) is to build a stand-alone gcc (arm-elf\static, say) then glibc, then gcc again.
It seems as though some have addressed the missing
crti.o
in an arm-linux target by modfiyinggcc\config\arm\t-linux
. Rather than relying on an unexisting glibc, the kludge is to use the arm-elf provided version of thecrti.o
. An example can be found here.