glibc

 历史证明，这是另一段disgusting 的旅程。。。

再恶心的旅程也要记录清楚，否则，下次岂不是更恶心了。。。

恶心之处在于，过程狠迷茫，这个工具做出来之后，根本没有人负责，文档很少，怎么编译根本不知道。

只能结合网上的留言来慢慢摸索。

之前恶心的几步回头再说，先说说现在恶心的步骤：

glibc要交叉编译，需要glibc-ports的支持，这个包是单独的，下载过后要解压并复制为glibc文件下的ports文件夹。

至于其余的patches从哪里下载和是否需要。。。下段分解。

关于参考文档，一开始觉得，应该是clfs比较正统，但是上面提到的ports再clfs里面并没有提到（是我看的不够仔细还是版本太老？）。

现在发觉龙芯lfs也是蛮正规的，现在两个都参考着呢。。。又报错了：我多么希望一遍到底。。。。

找不到config-name.h这个文件。这个文件是用来编译uname的，再仔细一看。。。uname提供的那几个参数基本上都是这个文件里定义的。。。

这个文件是configure glibc的时候自动生成的，这下问题就来了，configure的时候是怎么生成的这个文件呢，为什么我们的情况没又生成呢？

只好先手工写了一个蒙混过关了事。。。噢。。没有了事。。。也没有蒙混。。。这叫做并行处理。。。well done boy

。。。果然又出错了。。。

redefinition of "__stat" : 杠杠stat有重复定义， 其中一个定义在 ../include/sys/stat.h里面，另外一个在哪？glibc-2.9/io/stat.c : 50 在这里。。。

那就去glibc里面看看咯：我晕，这个文件就定义了这么一个函数。。。。。。。两个地方确实重复定义了。。看看咯。。。

加了一行 libc_cv_gnu89_inline =yes  到config.cache试试（config.cache是干吗的呢？）。过了，马上又出错了。。。libgcc找不到，这个还蛮乐观。

因为之前就发现在编译gcc442的时候只是编译了 make all－gcc这个target，后来在别人处还发现make  all－target－libgcc这个target

现在终于到了还债的时候了。。好在这个target狠顺利。但是继续报错 ， 狠不乐观的看到 －lgcc_eh 找不到了。。。。

这个libgcc_eh.a是要在编译gcc的时候enable－shared才能编出来的。。。好吧。。。重编gcc吧，希望可以成功。。。。或者说可以到下一个错误。。

显然glibc没这么好搞定，enable-shared需要crti.o这个文件，这个文件是谁生的？反正不是我。。。。。

这个看lfs狠明白的发现，lfs自己出了个patch把这个链接步骤给屏蔽了。。。。

不幸的是lfs的patch只是针对glibc28版本的，于是折腾到28版本，新的错误产生了。。。。真他妈锻炼人。。。

幸而找到一个29版的patch，打上了，编的风声水气。。。一气呵成。。。。一炮走红。。。总之是过了。。。

小忐忑的install一下：没想到这安装也是轰轰烈烈的，好在美出错。。。

再把gcc － full 搞定就算是拿下一城了。。。

结果噩梦 fixincludes又来了。。。。也算老朋友啦，看来要用clfs的几个神补丁来搞定之咯。。。。 

 这个和前面那个错误是一样的，crt1.o找不到。是时候搞定这个家伙了。。。

妖精是妖精他妈生的，crt1.o就是glibc生的，glibc的安装文件夹赫然在列，当初拿你没办法，现在可是收到擒来，先用ldconfig试试。

慢着，交叉编译哪来ldconfig？？？好吧，先用LD_LIBRARY_PATH吧 

貌似要用一个叫做crosstool的东西？问题狠简单，就是ld找不到那个文件而已。。。可是我要怎么和ld对话呢。。。ld，你好。。。

 由config.log 查到 xgcc 的查询路径，并且由查询路径查到，xgcc都再哪里搜索这个crt1.o  再把这些库拷到那里就可以了。。。

这个方法有点亡羊补牢。。。但是还是push through了一点点呢。。。其实这个问题不是无缘无故的造成的。。。

而是由于编译过程中路径的管理过于混乱，所谓路径管理，就是说在confgure的过程中，指定的路径不仅仅会影响到安装过程。

而且，特别是对于编译工具而言，这个路径还会影响到起搜索路径，所以这个prefix在指定的时候要仔细些。

下面遇到的问题就比较乐观了，被用来测试的程序不能运行。。。废话，交叉编译当然不能运行啦。。。。

话说回来这个编译出来的a.out到底是哪个平台的？当然是目标平台，否则还链crt1.o干吗。

这就有趣了，我们现在编译的是交叉编译工具，这些工具是在x86平台上运行的编译工具，因此也是x86平台的程序。

那么在配置的阶段，对这个xgcc的测试为什么要用交叉编译呢。。。这显然是不对，不知到是我配置错了，还是配置本来就是错的。。。。

只好改configure文件。。。我妈也不想这样。。。 

这样想来，确实由蹊跷的地方，为什么这个编译过程中xgcc要使用交叉编译？如果不是呢？还有就是为什么xgcc会指到了mips的ld呢。。。。

这个倒是最蹊跷的地方。。。。

(6月24号)补充，昨天之前其实还遇到一点，配置后，make ，直接出错，因为glibc-2.10.1的目录里面没有all这个目标。

今天用CLFS时候，也遇到了同样的问题，用了CFLS里面的一个sed招之后就好了：

这句是这样的：

sed -e 's/-lgcc_eh//g' Makeconfig.orig > Makeconfig

很神的一句，先敬下了。。。。