centos/ubutu x86-64 编译gcc-4.6.2 的经历

centos x86-64 编译gcc-4.6.2 的经历
1. 下载了gcc 的源码，是4.6.2 的版本， 本机的为4.4.7, 64bits 机器编译

编译经历
缺少gmp,mpfr,mpc, 要求高于一定版本。

自以为是的下载了高版本的gmp,mpfr,mpc, 随意选了自己喜欢的版本号. 这可能是问题的根源

gmp 选了5.0.5, mpf4 选了3.0.1, mpc选了1.0.2

multilib 的问题，忘了具体错误。想到了， --disable-multilib 选项
relocation R_X86_64_32 错误:  曾经在Makefile cflags 手工添加-fPID , 在当前目录下
  make clean; make; 虽能处理这个错误，但第二圈还会报这个错误，只能在修改走下去
LONG_MIN 未定义,  手工添加了LONG_MIN定义, #define LONG_MIN 0x80000000
size_t undefind,  手工替换了size_t, 使编译下去。
每一次的编译要等待很长时间才出错， 就这样持续了差不多半天。
发现自己的PATH 很长很复杂，精简到了最简单。
怀疑链接路径有问题,清理了ld-cache 目录
.h 缺失, 终于不堪忍受其折磨。
再后来莫名其妙的make[2],make[1]出错， 无心看它的Make链，才开始想办法。
发现自己的PATH 很长很复杂，精简到了最简单。
怀疑链接路径有问题,清理了ld-cache 目录


gcc 的编译 INSTALL 也看了,没看出所以然.


直到看见了一篇简明的安装步骤: 才进入了正常轨道,如下操作:
1.下载源码
wget http://ftp.gnu.org/gnu/gcc/gcc-4.6.2/gcc-4.6.2.tar.gz
tar -xzvf gcc-4.6.2.tar.gz

2.下载依赖./contrib/download_prerequisites

版本号,gmp(4.3.2),mpfr(2.4.2),mpc(0.8.1)　

连编都不用 , 不要自做主张下载别的版本

3. 配置
mkdir build-4.6.2
cd  build-4.6.2
../gcc-4.6.2/configure --enable-checking=release --enable-languages=c,c++ --disable-multilib

4. 编译

make -j2
一个错误都没有，就是编锝时间长，半个小时吧。

5. 安装
make install


总结:
开源软件编译
1. 编译选项很重要，要阅读其README, INSTALL 等文档
2. 依赖关系很重要，最好要它推荐的版本，不能随便用
3. 出现莫名其妙的错误，不要试图自己解决。要查找原因和解决办法.
   不过当走错路时，网上说法鱼龙混杂，一片嘈杂，自己斟酌辨别.
4. 开源的东西，顺利的话应该很简单的， 应该是傻瓜操作。
   不过碰到问题，会让你学到不少东西.

由于很痛苦，所以我记录，总算云开雾散。

------------------------------------------------------------------------------------

ubuntu 下编译gcc-4.6.2

------------------------------------------------------------------------------------

本以为会很顺利，其实不然。
问题1：
/usr/include/features.h:324:26: fatal error:
bits/predefs.h：没有那个文件或目录

是gcc 版本过高4.6.3，编译4.6.2出问题,应该降级才能解决, 降为4.4
可以apt-get remove 高版本， apt-get install 低版本.
有人说了，版本安装这么方便，你干嘛非自己编译折腾gcc ?
是啊，ubuntu 的apt-get, centos 的yum 使我们的系统管理非常方便，
在此表示感谢，但有时候我们需要自己动手，丰衣足食。

问题2
configure: error: C preprocessor "/lib/cpp" fails sanity check
是c++包没有安装，
apt-get install gcc-g++

问题3：
cannot find crti.o: No such file or directory
因为是第二个round stage 出的问题，所以怀疑是 glibc 编的有问题??，
事实上不是，先make distclean, 重新编译
还是出现问题，止步于此，
再去掉了disable-multilib试试，还是如此

原来要为头文件及库建立软链接
cd /usr/include
ls -s x86_64-linux-gnu/bits/ bits
ls -s x86_64-linux-gnu/gnu/ gnu
ls -s x86_64-linux-gnu/asm/ asm

cd /usr/lib
sudo ln -s x86_64-linux-gnu/crt1.o crt1.o
sudo ln -s x86_64-linux-gnu/crti.o crti.o
sudo ln -s x86_64-linux-gnu/crtn.o crtn.o

再编译，成功，不要倒在黎明前
为什么加链接可以成功，其实没有搞清楚。
我们知道编译gcc 有三个过程。即三圈.
1。 用旧版本gcc 编译代码生成新gcc，只要旧版本正常，会编译通过，
    这一般不会有问题。但问题是，编出的gcc 能否胜任gcc. 看round 2
2. 用新版本gcc 编译代码。 问题往往出在这， 也是你等很久的原因。
3. 用最新版本再编一遍代码，与第二遍比较，这一般也不会出问题。
那第一遍难道就没有编出crti.o吗？ 为什么第二遍找不到呢？加的这个链接
x86_64-linux-gnu 又是什么呢？ 它到底是静态的还是动态的，有空再研究，

收获还是3句话，1，编译的环境要干净. 2. 依赖要正确。3.遇到问题要冷静.

有空还可以做一下交叉编译，一定会更有收获。

通俗的解释是: 编译复杂的开源软件好比请财神，首先要打扫庭院，洗洗澡，换上干净衣服。

财神一看你穿得破破烂烂，是不来的。

第二，要把财神喜欢吃的猪头，腊肉，水果等贡品备好，否则它也不干活。

第三，财神可能还是没显灵，或者嫌你的院子赃，或者是吃坏肚子了。财神又不是医生。问它哪不舒服，

         它也说不准，可能水果不干净，或者牛肉没炖好，反正就是肚子疼。

        谁是医生呢？孤哥，度娘是医生， 虽然是个千里眼，不过眼神并不好，具体斟酌还得你自己。

折腾ubuntu下gcc 编译，又到了半宿。

补充一下，配置为: ../gcc-4.6.2/configure --enable-checking=release --enable-languages=c,c++