LinuxSir.cn,穿越时空的Linuxsir!

 找回密码
 注册
搜索
热搜: shell linux mysql
查看: 2375|回复: 6

u-boot编译为什么还需要glibc的头文件?交叉编译,glibc和内核到底谁依赖谁?

[复制链接]
发表于 2008-10-29 04:56:08 | 显示全部楼层 |阅读模式
编译u-boot需要哪些额外的头文件?

我在windows下用MinGW+MSYS+GNUARM来交叉编译u-boot,提示一些头文件找不到,查了一下,是glibc库中的文件。
我感到很奇怪,按照我的理解,bootloader编译时需要的头文件应该全部都在它的代码包中,而不应该再依赖其它的头文件了吧。
因为它不应该依赖别的包运行才对啊。bootloader运行时还根本没有运行时库这么一说呢。

进一步想想,如果必须要glibc包的话,我只能下一份glibc的源码包自己做交叉编译对吧?而且不能下devel包,因为devel包中已经编译好的lib文件应该不是arm处理器的机器码。
而再进一步想,c运行时库的实现应该是高度依赖具体的操作系统的啊,比如基本的文件读写,一定得产生具体的系统调用才能完成。那么我要是想交叉编译glibc,就不得不先找一份linux的源码,先交叉编译整个嵌入式linux系统!
然后刚才又上网查了一下,更是晕死,编译内核需要glibc包的支持……
这不成了先有鸡还是先有蛋的问题了么。

哪位高手,明白人,帮我梳理一下这团乱糟糟的思路,不胜感激!
发表于 2008-10-31 23:22:28 | 显示全部楼层
个人认为,内核本身不依赖于glibc。我估计是编译过程中的一些工具(比如压缩,读写工具等需要实用依赖glibc的工具程序)。具体原因还请楼主贴出具体的错误信息。然后共通分析一下。
回复 支持 反对

使用道具 举报

 楼主| 发表于 2008-11-1 07:15:53 | 显示全部楼层
谢谢楼上的回复!果然是一些额外工具的导致的问题。

现在我再次仔细看了一下细节,发现需要glibc库文件支持的是u-boot/tools之中的可执行文件,也就是说,这个可执行文件应该是用我的系统中的gcc编译,并依赖当前系统中安装的c运行库的本地代码,跟u-boot无关才对。出错的原因显而易见,MinGW用的是自己的c运行库,系统中根本没有glibc嘛。看来我没法在windows系统中编译这些工具了,除非想办法把源代码向MinGW移植,但现在没时间,我还是老老实实地到虚拟机里去编译的好。

我想u-boot自身的编译应该是不用额外的库或头文件支持才是,无奈我make中上一步出错,还到不了编译u-boot的那一步。稍后我得验证一下。

这两天愁于这个问题四处瞎转,终于看到LinuxSir上的大牛youbest写的《clfs2.0原理分析》,茅塞顿开的同时也感慨,从一个看起来很小的问题,竟然扯出来这么复杂的一大套东东,呵呵。

btw:另外我也支持楼上的观点,内核的编译应该是不依赖什么额外的库或头文件的吧。虽然我还没有实际验证过,但想来如此。

我自己的两个问题,现在按照我自己的理解大致解释两句,不对的话请指正。
1. 首先,linux内核的编译应该不依赖于其他库。我们应该可以通过使用特定的参数,编译得到内核头文件。
2. glibc的工作是需要内核的支持的,所以编译glibc的时候需要用到特定版本的内核头文件,由上一步可以得到。(我想是不是直接从内核源码里拷贝出来也可以,呵呵。)
回复 支持 反对

使用道具 举报

发表于 2008-11-4 22:30:10 | 显示全部楼层
内核一定不会依赖Glibc的
回复 支持 反对

使用道具 举报

发表于 2008-11-4 22:32:13 | 显示全部楼层
u-boot本身是可以不依赖Glibc的,标准的用法也是如此。试想,u-boot本身是Bootloader,Bootloader阶段内核还没有启动,并没有Glibc的运行环境,事实上例如字符处理等C语言的库函数,在boot等Bootloader中都是自己实现一份
回复 支持 反对

使用道具 举报

发表于 2008-11-15 15:22:01 | 显示全部楼层
至少 u-boot 的内核镜像并接工具 mkimage 是依赖 glibc 的,他是在你的上位机运行的工具啊。
回复 支持 反对

使用道具 举报

发表于 2008-12-6 15:56:18 | 显示全部楼层
主机工具的依赖
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

快速回复 返回顶部 返回列表