LinuxSir.cn,穿越时空的Linuxsir!

 找回密码
 注册
搜索
热搜: shell linux mysql
123
返回列表 发新帖
楼主: 地球发动机

用GCC 4.3-20040810构造SYSROOT工具链

[复制链接]
发表于 2008-4-18 00:58:48 | 显示全部楼层
可以2遍完成gcc,不错。

第一遍编译gcc时,也是需要补丁的,不然会像你一样引入host系统 gcc spec 或 像我一样使用 make -C gcc 。解决这个问题 lz 的方法就比较完美了。

查看官方邮件列表,暂时没有看到谁提交gcc-4.3的CLFS-system方法。只是有人提到用gcc-4.3完成LFS的。
回复 支持 反对

使用道具 举报

 楼主| 发表于 2008-4-18 07:25:08 | 显示全部楼层
Post by 1987a;1839431
有些道理。
不过应用你的补丁,ccheaders这一行会多出一个 -isystem ,感觉怪怪的。

这里有些奇怪,完成第一编 gcc 后,运行tools 下 x86_64-unknown-linux-cpp -v ,可以清楚的看到 include-fixed 在系统头文件搜索路径下,但编译 glibc 居然要要用 -isystem 指明。


这一点都不奇怪。由于Glibc的自足性,Glibc不可以依赖于任何系统头文件,所有头文件都必须明确指定。所以配置脚本要调用gcc来获得头文件位置。

ccheaders这里多出一个-isystem是有些怪。不过这也是不得已。我想,要是做个正式补丁而不是sed补丁,那么我们可以添加一个ccfixedheaders变量,然后让SYSINCLUDES把它包括在内。但这要是做sed补丁的话,因为修改的行数多,就有些麻烦了。
回复 支持 反对

使用道具 举报

发表于 2008-4-18 13:28:55 | 显示全部楼层
Post by 地球发动机;1839454
这一点都不奇怪。由于Glibc的自足性,Glibc不可以依赖于任何系统头文件,所有头文件都必须明确指定。所以配置脚本要调用gcc来获得头文件位置。

ccheaders这里多出一个-isystem是有些怪。不过这也是不得已。我想,要是做个正式补丁而不是sed补丁,那么我们可以添加一个ccfixedheaders变量,然后让SYSINCLUDES把它包括在内。但这要是做sed补丁的话,因为修改的行数多,就有些麻烦了。


用sed也很简单的,可以在ccheaders这行下附加一行
sed -e '/ccheaders.../a
ccheadersfixed=...' ...。

glibc 需要 内核头文件 和 系统头文件 来提供 平台相关支持,自足体现在glibc仅用一个gcc裸编译器就可以完成编译。
回复 支持 反对

使用道具 举报

 楼主| 发表于 2008-4-18 13:46:20 | 显示全部楼层
Post by 1987a;1839601
用sed也很简单的,可以在ccheaders这行下附加一行
sed -e '/ccheaders.../a
ccheadersfixed=...' ...。

glibc 需要 内核头文件 和 系统头文件 来提供 平台相关支持,自足体现在glibc仅用一个gcc裸编译器就可以完成编译。

为什么glibc仅用gcc编译器就够了呢?因为glibc不相信任何默认的头文件。那些头文件可能属于以前的glibc版本,甚至是来自uclibc或者其它系统的。所以,它必须了解每一个头文件的位置。比如说,内核头文件是通过一个选项来告知glibc配置脚本的,gcc头文件是直接询问gcc而检测到的,等等。因此,即使gcc已经把所有的头文件搜索路径正确设定了,glibc还是只能通过那个脚本来了解gcc头文件的所在。这样当某个头文件被移动了,原先的脚本就不能检测新的头文件位置。
对此,你可以在编译的过程中临时中断,观察编译所用的命令。你可以看到,glibc的确是用了一个参数来关闭gcc头文件默认路径的。具体什么参数,我这里就不说了。
回复 支持 反对

使用道具 举报

发表于 2008-4-18 14:02:45 | 显示全部楼层
Post by 地球发动机;1839607
为什么glibc仅用gcc编译器就够了呢?因为glibc不相信任何默认的头文件。那些头文件可能属于以前的glibc版本,甚至是来自uclibc或者其它系统的。所以,它必须了解每一个头文件的位置。比如说,内核头文件是通过一个选项来告知glibc配置脚本的,gcc头文件是直接询问gcc而检测到的,等等。因此,即使gcc已经把所有的头文件搜索路径正确设定了,glibc还是只能通过那个脚本来了解gcc头文件的所在。这样当某个头文件被移动了,原先的脚本就不能检测新的头文件位置。
对此,你可以在编译的过程中临时中断,观察编译所用的命令。你可以看到,glibc的确是用了一个参数来关闭gcc头文件默认路径的。具体什么参数,我这里就不说了。


请注意我说的是 gcc裸编译器 不是 gcc编译器。
另外,内核头文件位置,我们是在配置glibc时提供的,glibc不依赖除编译用gcc提供的系统头文件之外的其它系统头文件。

"glibc的确是用了一个参数来关闭gcc头文件默认路径的" 搞清楚一点,不错!
回复 支持 反对

使用道具 举报

发表于 2008-6-24 02:42:02 | 显示全部楼层
lz报给官方的bug,实际上不是bug,编译最终gcc时,指明--build与--host相同即可正常编译。

请参考 [color="Blue"][原创]从源码构建本地编译GNU/Linux系统(gcc-4.3.1)
回复 支持 反对

使用道具 举报

发表于 2011-12-11 19:51:40 | 显示全部楼层
收藏,收藏,收藏
回复 支持 反对

使用道具 举报

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

本版积分规则

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