[原创]从源码构建本地编译GNU/Linux系统（gcc-4.3.1）

聚焦深空

Post by 地球发动机;1875325

这是两遍。因为完整的顺序是
naked GCC
Glibc-headers
static GCC
Glibc
GCC final
如果把GCC final看作单独的步骤，那么naked也应该是单独的步骤。

有点明白你的意思了，我们x86/x86_64方法配置安装Glibc-headers时，要使用宿主gcc代替仍不存在的交叉编译工具链中的${NEW_OS_TARGET}-gcc，这个只要宿主gcc支持配置安装Glibc-headers过程中的参数即可。

i486-pc-linux-gnu -> mips-unknown-linux-gnu验证表明，需要宿主gcc支持参数“-mabi=32”，所以解决方法有三，一是给宿主编译一个支持这个参 数的编译器，二是给glibc源码打补丁暂时屏蔽对-mabi=32参数的调用，三是使用--with-newlib编译第一遍gcc，跳过glibc- header。
i486-pc-linux-gnu -> mips64-unknown-linux-gnu验证结果类似。

我会优选方法二，youbest也是使用的方法二，你可以参考一下“sed -i 's/-mabi=$mips_config_abi//g' ports/sysdeps/mips/preconfigure“

事实是仅需要编译gcc两遍，配置安装Glibc-headers过程中，欺骗一下就可以的，并不需要真正的交叉编译。

地球发动机

Post by 聚焦深空;1875424
有点明白你的意思了，我们x86/x86_64方法配置安装Glibc-headers时，要使用宿主gcc代替仍不存在的交叉编译工具链中的${NEW_OS_TARGET}-gcc，这个只要宿主gcc支持配置安装Glibc-headers过程中的参数即可。

i486-pc-linux-gnu -> mips-unknown-linux-gnu验证表明，需要宿主gcc支持参数“-mabi=32”，所以解决方法有三，一是给宿主编译一个支持这个参 数的编译器，二是给glibc源码打补丁暂时屏蔽对-mabi=32参数的调用，三是使用--with-newlib编译第一遍gcc，跳过glibc- header。
i486-pc-linux-gnu -> mips64-unknown-linux-gnu验证结果类似。

我会优选方法二，youbest也是使用的方法二，你可以参考一下“sed -i 's/-mabi=$mips_config_abi//g' ports/sysdeps/mips/preconfigure“

事实是仅需要编译gcc两遍，配置安装Glibc-headers过程中，欺骗一下就可以的，并不需要真正的交叉编译。

谢谢指教。方法三在GCC 4.2系列是好使的，但到了4.3就不行了。

聚焦深空

Post by 地球发动机;1875514
谢谢指教。方法三在GCC 4.2系列是好使的，但到了4.3就不行了。

没道理，如果我真的准备用newlib的c库怎么办？回头研究下。

聚焦深空

oom kill的问题最新进展如下： 升级到binutils-2.18.50解决。

地球发动机

Post by 聚焦深空;1875541
没道理，如果我真的准备用newlib的c库怎么办？回头研究下。

经过最新研究，阻止GCC 4.3在没有头文件的情况下静态编译的因素有两个：
1、decimal-float的支持需要宿主头文件FENV.h。这可以通过参数--enable-decimal-float=no禁止掉。
2、现在Linux下编译的线程模型默认为posix。且即使使用--disable-threads或者--enable-threads=no 甚至--enable-threads=single都会被忽略。这一点在本机编译的情形下验证。这个需要一个补丁：
cp gcc/configure{,.orig}
sed -e s/x\$\{thread_file\}/x/ gcc/configure.orig >gcc/configure

目前还在研究这样编译的gcc是否能编译glibc。

顺便说一下，我觉得第二点绝对是一个BUG，因为configure.ac的相关内容如下
if test x${thread_file} = x; then
  # No thread file set by target-specific clauses in config.gcc,
  # so use file chosen by default logic above
  thread_file=${target_thread_file}
fi
这里指出：仅当config.gcc文件里面没有设置线程库的时候，才会根据“以上逻辑”设置变量thread_file。但所谓“以上逻辑”正是检查用户设置的代码。因此，如果config,gcc能够检测到线程库，用户指定的设置就不再起作用。

更新：最新研究发现，GCC4.3比以前的版本更依赖于--build的设定。关于线程的设置，如果没有--build参数，则以上提到的config.gcc脚本会强行设置thread_file参数，把用户设置覆盖掉。
结论是：在GCC4.3即使要进行本机编译，最好也加上--build参数。采用这种方法，就不需要补丁。

聚焦深空

Post by 地球发动机;1876520
结论是：在GCC4.3即使要进行本机编译，最好也加上--build参数。

本地编译时，没必要添加--build，除非想移植系统到新机，并保持兼容性，这样还需要CFLAGS="-mtune=xxx -march=xxx"、CXXFLAGS=$CFLAGS配合。

地球发动机

Post by 聚焦深空;1876902
本地编译时，没必要添加--build，除非想移植系统到新机，并保持兼容性，这样还需要CFLAGS="-mtune=xxx -march=xxx"、CXXFLAGS=$CFLAGS配合。

我不是说了吗？4.3要是不加--build，那么--disable-thread参数可能不能生效。为了在没有头文件的情况下编译4.3，就要加--build。

聚焦深空

Post by 地球发动机;1877021
我不是说了吗？4.3要是不加--build，那么--disable-thread参数可能不能生效。为了在没有头文件的情况下编译4.3，就要加--build。

呵呵，你前面说的是本机编译，我理解为本地编译不为过吧。
我帖子中给出的建立交叉编译工具链的方法一直有加--build，目的只是保持一致和对称，顺便也省去你上面的麻烦。

其实，没必要与glibc-header较劲的，本质上，安装glibc-header是为了解决gcc glibc循环依赖问题，后面步骤安装glibc时，会把前面安装的glibc-header覆盖，第二次安装的glibc-header才是我们真正需要的。

参考 google 到的资料http://gcc.gnu.org/ml/gcc/2008-06/msg00181.html，CLFS-1.x，gcc-4.3.1源代码，还有你的帖子。
经验证，sysroot方式，不安装glibc-header的情况下，gcc第一遍配置时需添加下面参数，应当也适用于gcc-4.2.x：

1.                 --with-newlib \
2.                 --disable-threads \
3.                 --disable-decimal-float \

复制代码

除了上面变动，建立交叉编译工具链的其他步骤不需改变，已建立完整交叉编译工具链验证。
下次全面升级系统时，我会考虑使用这种方法，到时再合并到第一贴。

其间，曾尝试古老的libchack方案，通不过。