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

编译u-boot需要哪些额外的头文件？

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

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

哪位高手，明白人，帮我梳理一下这团乱糟糟的思路，不胜感激！

个人认为，内核本身不依赖于glibc。我估计是编译过程中的一些工具（比如压缩，读写工具等需要实用依赖glibc的工具程序）。具体原因还请楼主贴出具体的错误信息。然后共通分析一下。

谢谢楼上的回复！果然是一些额外工具的导致的问题。

现在我再次仔细看了一下细节，发现需要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的时候需要用到特定版本的内核头文件，由上一步可以得到。（我想是不是直接从内核源码里拷贝出来也可以，呵呵。）

内核一定不会依赖Glibc的

u-boot本身是可以不依赖Glibc的，标准的用法也是如此。试想，u-boot本身是Bootloader，Bootloader阶段内核还没有启动，并没有Glibc的运行环境，事实上例如字符处理等C语言的库函数，在boot等Bootloader中都是自己实现一份

至少 u-boot 的内核镜像并接工具 mkimage 是依赖 glibc 的，他是在你的上位机运行的工具啊。

主机工具的依赖