哈哈！build gnu c compiler OK！

snow888

不说话了，看图。

sunlan

把过程贴出来，给你加精

snow888

sunlan 发表于 2012-04-02 08:07
把过程贴出来，给你加精

老大，其实就是两个二次编译，然后将 ld 拷贝到 /bin 和 /usr/bin , 结果就成这样子了。

不过程序代码修改的量比较大。第一次编译没有要修改的地方，就是按照你的那个方法实现的。

然后用编译的 gcc 编译 binutils 这个软件包。这个软件包需要在这个源码的根目录下进行编译，这次编译也不需要修改程序代码，编译完成以后，不能直接安装，还得进入到 ld 目录（默认这个目录是不编译的，这也是开始我编译的很久就是没有 ld 的原因），再次编译 ld ，然后再 make install 进行安装

安装 ld 之前，需要将 ldmain.c 文件进行一下修改。前面编译的 gcc 会在调用 ld 时传入一个 -Qn 的参数，这个参数 gnu ld 是不支持的，我们在 ldmain.c 最前面就将其屏蔽掉（对 argv 的参数进行处理 ）。


二次编译 gcc ，第二次编译时需要带上 --with--gnu-as 和 --with-gnu-ld 的参数，这次编译，你会发现原来能正确编译的程序代码，这次无法通过了，原因就是前面你用的是 sco 自带的 as 汇编和 ld 链接，而这次用的是 gas 和 gld ， 所以通不过了，没有办法，改程序吧。

这个程序我改了有两三天，google又不给力。找资料很郁闷，当时只想解决问题，也没有及时整理。主要是编译通不过的地方，另外就是 在 sco 上默认不会将 elf 和 coff 的二进制格式包含进来（具体见 gcc 下面有一个 README.SCO) ，好像是因为 SCO 和 gnu 的官司问题。所以需要将 binutils/include 下的那些定义的 aout、elf、coff、opcode、nlm 等文件格式包含到 gcc 里面来，然后将 binutils 目录下的 bfd 目录的文件在 gcc 里面包含进来，在形成汇编码之前要对处理的这些个程序代码形成的汇编前面添加出这些文件的格式头信息。


再次编译你的 gcc ，如果没有问题，那么恭喜，你已经成功了一半。

二次编译 binutils 软件包，这次编译，你会发现 这个 binutils 又编译不过了，原来已经能正确通过的，现在又通不过了。

原因还是因为你这个时候的 ld 还是调用的标准的 ld 下的格式信息文件，不是自己的标准的格式信息文件，你修改完成的 gcc 传入的时候，这个 ld 反而又不认了，没关系，我们再改。

需要指出的是，这次的编译你得带上 BUILD_PATH ，这个参数指定你的ld 从哪个地方链接标准库，这是关键，否则你的 gnu ld 还是会链接你的系统的标准库，而不是你自己构建的标准库 。

一边编译，一边修改，直到你的编译通过，那么好，这个时候，你已经有了一个基本的编译环境了。

再来，

我们开始安装 glibc ， 这个包就是和原生的标准库包一样的咚咚，貌似函数库还丰富一些。

这个咚咚用你自己的 gcc 编译，修改的地方不多，大概有 20 ~30 处左右，改完就完事了。

安装完成以后，你就已经有了一个基本的系统了。

下面再就是安装一些工具了，比如说gettext、autogen、dejagnu、fsu-thread-3.1.4 等等。这些咚咚几乎是没有改动，直接就过去了。

好像 fsu-threads 有两个头文件要改动，socket.h 里面有几个信息需要定义一下。signal.h 里面有大量的 define 需要定义一下 , errno.h 中加一个 extern int h_errno 。

最后，我们为了让这个咚咚脱离原生的编译环境，就直接将 ld 和 as 替换到系统上去了，有两个 一个是 /bin 下面，一个是 /usr/bin 下面（原生的建议不要删除，我也不知道删除了有问题没有，还是保留吧，可以换一个名字，比如说 old_xx 之类的）。

sunlan

那个和make bootstrap什么差别？

snow888

回复 4# sunlan


    gcc 是通过 make bootstrap 出来的，那个 binutils 的不是，除非你显示的强制使用 --enable-bootstrap ，否则使用 make bootstrap 会报错误。

这其中的复杂部分就是两次编译的理解，可以再引申一下。

如果这个工作是在一个独立的硬盘上面进行操作，那么你可以将这个独立的硬盘分出一个 /boot 、/swap、/home、/usr 等。

当你的这个编译环境在这个独立的硬盘上搭建好了以后，你可以将其他的操作系统的内核源码，头文件等，使用这个编译器进行编译并安装到你的这个目的盘上，这将使得你编译的系统脱离原来的环境，如果你同时编译了 bootloader , 并构建了自己的 grub ，那么当你卸载这个硬盘并拿到独立的另一台机器上使用，你实际上已经在一个交叉编译的环境中利用 sco “生”出了一个另外的操作系统和开发环境。

我的灵感也就是来源于此。

另外：

那个需要修改的内容很多很多，我也是遇到问题后在网络上 google 的，这里我只说了实现的方法。

主要的来源是 gnu 的 bug 报告，也有一些老外的论坛上的解决方案（不是针对我的这些动作的，实际上只是有借鉴意义。）

那个东西要完整些出来估计是不太可能了，因为我做的时候根本就没有整理。

修改得多的地方主要是 opcodes 部分、i386 部分（因为我的环境是 i386 的，其它的系统环境需要根据自己的环境进行修改）、bfd 部分、libiberty 部分。

有部分修改的是 ld 和 gas 部分、gcc 里面也有一些修改，主要是编译的时候报错就找资料改出来的。

可执行文件的部分，仅仅是文件头的格式不同，调用时的地址定位部分不一样，具体内容可参照 aout、elf、coff 部分来看，真正执行的代码部分，由于与机器的架构有关，只要是同一个硬件系统架构的，执行部分都是一样的。

如果有兴趣，也可以自己构造一个可执行文件的格式结构，当然这个与你的操作系统对执行文件的调用方式有关，比如 elf 就与 linux 调用执行文件的方式紧密相关的，而 ibcs2 则与 sco 系统对可执行文件的调用方式有关。

这主要是不同的操作系统的不同优化。

我大概知道的也就是这么多了。

老大，能否加精华啊。

snow888

我这个严格说也做得不成功，生成的部分程序好像也与 /usr/ccs/lib/libc.so.1 有关，这个是 sco 的原生的系统链接库，我的目标是彻底脱离 sco 的系统。

另外：我做这个本来是用它来编译另一个行业软件的，结果发现这个 gcc 的版本还是低了，没法儿编译，主要是 gcc 的内链函数有部分没有（这个内链函数不是我们编程中用到的，实际上是对程序员不可见的）。倒是 sco 6 版本的原生的 cc 能编译，所以我又把这个环境给干掉了。

很是郁闷的说。