速度与激情(一) 编译优化参数

ayun2001

LFS官方教程是不推荐我们优化编译LFS,但是追求速度和激情的我们实在不能忍耐没有优化的系统.最后经过我多次编译LFS的经验将LFS编译优化的一些心得写出来.

大家都应该看过第二章中设置 完成 lfs 用户的环境配置后执行 source ~/.bash_profile 命令后,在lfs用户状态执行下面几条命令:

export CFLAGS="-march=pentium4 -O3 -fomit-frame-pointer -pipe"
export CXXFLAGS="-march=pentium4 -O3 -fomit-frame-pointer -pipe"
export LDFLAGS="-Wl,-O1 -Wl,--sort-common -s"
export CPPFLAGS="-DNDEBUG"

这样每次编译的程序都会将编译优化参数自动添加到Makefile中~ 这个参数只用与Intel P4 CPU的平台~ AMD的平台需要另外调整.

在运行make程序的时候记得在后面添加 -j3 参数 这样你的make 编译过程大大加快了~

好了 我们让我们开始构建LFS时候感受它的速度与激情吧~ :rolleyes:

d00m3d

虽然我也热衷於使用编译优化参数，但 LFS 官方教程不推荐使用是有原因的，特别是 toolchain （即 binutils/gcc/glibc）的建构上

说真的我发现：
1. 在我的系统里 binutils 是必死无疑的
2. gcc 其实在 bootstrap 的时候自动把自定义优化参数去掉了，改以它自己的参数如 -O2 之类来进行的
3. glibc 不详，是能通过了，效果好像不明显，但我是升级 glibc 时使用的，而非建立系统的 toolchain 时使用

以前有前辈说在建立系统的 toolchain 时使用优化参数後，到 BLFS 的时候有很多东西出问题，结果要把系统重做

是否能感受它的速度与激情，还是要感受重做系统的激动？福兮？祸兮？

我的建议是建立 toolchain 的时候还是保守一点点吧

ayun2001

Post by d00m3d

说真的我发现：
1. 在我的系统里 binutils 是必死无疑的
2. gcc 其实在 bootstrap 的时候自动把自定义优化参数去掉了，改以它自己的参数如 -O2 之类来进行的
3. glibc 不详，是能通过了，效果好像不明显，但我是升级 glibc 时使用的，而非建立系统的 toolchain 时使用

1.binutils 2.17 确实必死无疑~ 但是binutils 2.16.1 却稳定不少!
2. gcc bootstrap中间2次自动编译去掉优化 十分有必要的~ 如果要修改二次编译的参数Makefile里面可以调整,个人也十分同意编译链"防污染"这个重要概念,这个GCC自动调整,个人觉得没有必要手动调整~
3.glibc 2.3.6 比以后的版本出现问题要少不少~ 个人不太喜欢 glibc 2.3.6 以后的版本但是还是观望的态度接受新版本

d00m3d

我不是太清楚 glibc 版本之间的区别，升级後系统性能是增快了

升级前是 gcc-4.0.3/glibc-2.3.6，升级後是 gcc-4.2/glibc-2.5，但我不能判断是新版 glibc 所致，还是因为新版 gcc 所致，估计是後者

glibc-2.6 还未打算升级，观望中

ayun2001

恩!~ 我现在对glibc 2.5 仍然是观望 不想冒然升级到 glibc 2.5  毕竟新东西很多没有掌握 呵呵~

youbest

速度是有了，但激情还不够～

manphiz

我认为全局使用 -O3 不是激情，而是自杀行为

另外， glibc-2.5 和 glibc-2.6 只是添加新的 RFC ，与 glibc-2.4 是 ABI 兼容的，实际上没什么大变化。各位可以放心升级

fuch

个人觉得-O2比较稳妥