环境: Ubuntu 10.04 Gcc 4.4.3 Glibc 2.9
Glibc的编译完全是在一路的错误总走过来....GNU网站上写的很明白，编译glibc是一个非常ugly的过程，看来所言不虚。一番努力都搞定。简单的一些笔记在这里，供其他朋友们参考
在源代码更目录下，生成如下的标志传递给gcc, 注意文件名可不要打错，另外我这里是i686，如果你是i486那么你需要改变一下参数里的i686为i486
echo "CFLAGS +=-O2 -D_FORTIFY_SOURCE=2 -march=i686 -mtune=native -fno-stack-protector" >configparm
这个-D_FORTIFY_SOURCE很重要，后面在多个地方会引起编译不过，可以针对编译无法通过的.c，单独的修改他们的Makefile，使用
-U_FORTIFY_SOURCE 来局部的取消这个标志，这样就可以正确的编译通过。当你遇到 syslog函数体无法找到, signlongjmp 重名等等错误时，首先考虑下这个标志把。或者有个一劳永逸的办法，这也是国外论坛上推荐的办法，那就是全局的撤销_FORTIFY_SOURCE,这样参数就变成了:
echo CFLAGS +=-O2 -U_FORTIFY_SOURCE -march=i686 -mtune=native -fno-stack-protector > configparms
这几乎就避免了大部分的编译错误。我编译时候还遇到了如下的问题：
readlink_chk.c : __readlink_chk() 函数和 unistd.h中的声明不统一，查看了源代码后我将readlink_chk.c中的声明改为和unistd.h中一致，并加上#if defined __USE_BSD || defined __USE_XOPEN_EXTENDED || defined __USE_XOPEN2K 定义保护，这个.c中还有至少一个其他函数也有这个问题，我是改了代码编译通过。
编译完回头再看，大部分问题都是由于 -D_FORTIFY_SOURCE=2 引起，抽空要研究下这个标志到底意义何在，后面研究完了再发一篇文章好了，最近大部分时间都被mac os夺取了:-)
posted on 2011-11-23 23:19
无毁湖光 阅读(105)
评论(0) 编辑 收藏 引用