glibc-2.11 已发布挺长时间，貌似大家很平静

聚焦深空

http://sourceware.org/ml/libc-alpha/2009-10/msg00063.html
这次 tarball 在发布后不久有提供，按惯例仍不是由 Ulrich Drepper 提供。
string 一族函数有针对 x86 x86_64 优化，应该能带来微量性能提升。

暂未看到 eglibc 跟进。

pinkme005

深空兄先升级一次 libc试试，效果好的话我们也试试

聚焦深空

升级可以随便挑一个晚上，让机机自己做。

顺便可以升级下
gcc-4.4.2
binutils-2.20

不急，等 gcc-4.5 linux-kernel-2.6.32 发布后一起升，看起来不错。

d00m3d

以往我都算敢死隊，但上次 glibc-2.8 令我後悔非常，自此以後我也很小心了，還是靜觀其變為上

我用過 gcc-4.5 兩星期前的 snapshot，效能暫時未見明顯，只是編譯出來的內核好像是快了一點點，有待證實，可是代價可不少，編譯所需的時間長近倍。

另一個常用的軟件 wine 在 4.4.2 需時 40 分鐘，但 4.5 卻要 78 分鐘，編譯雖然是通過了，但卻不能跑 win 的軟件，gcc-4.5 離可用的時間還有段很長距離。

飞龙在天

Linux 软件版本间的不兼容性，真是让人头痛。为什么就不能100%兼容呢？

pxbfeiniao

玩gentoo，昨天已经升级完毕。
话说回来，lfs只是让我们深入（具体怎么深入，因人而异）了解linux的构建过程。日常使用还是非常不方便。

聚焦深空

楼上兄弟，能在这个版坚持下来的，大多没有门户之见，且早超脱于 LFS/CLFS 本身。
使用的包管理方法更是八仙过海。

按 gentoo 的说法 "一切皆可选择"，请尊重别人选择的权力。
个人之见，gentoo 不错，尤其是其手册，可惜对其包管理无爱，另 portage 过于肥硕。

junglevass

还是port 方便

聚焦深空

Post by d00m3d;2043759
我用過 gcc-4.5 兩星期前的 snapshot，效能暫時未見明顯，只是編譯出來的內核好像是快了一點點，有待證實，可是代價可不少，編譯所需的時間長近倍。

http://gcc.gnu.org/gcc-4.5/changes.html

General Optimizer Improvements

   

• The -save-temps now takes an optional argument.  The     -save-temps and -save-temps=cwd switches write     the temporary files in the current working directory based on the original     source file.  The -save-temps=obj switch will write files into     the directory specified with the -o option, and the     intermediate filenames are based on the output file.  This will allow the     user to get the compiler intermediate files when doing parallel builds     without two builds of the same filename located in different directories     from interfering with each other.
  
• Debugging dumps are now created in the same directory as the     object file rather than in the current working directory.  This     allows the user to get debugging dumps when doing parallel builds     without two builds of the same filename interfering with each other.
  
• The Multiple Precision     Complex Library (MPC) is now used if found at configure time.     This allows GCC to evaluate calls to complex built-in math functions     having constant arguments at compile-time and replace them with their     mathematically equivalent results. Some complex functions were     supported before; for those a fall back is used if MPC is not     available.
  
• A new link-time optimizer has been added (-flto).     When this flag is used, GCC generates a bytecode representation of     each input file and writes it to special ELF sections in each     object file.  When the object files are linked together, all the     function bodies are read from these ELF sections and instantiated     as if they had been part of the same translation unit.  This     enables interprocedural optimizations to work across different     files (and even different languages), potentially improving the     performance of the generated code. To use the link-timer optimizer,     -flto needs to be specified at compile time and during     the final link. If the program does not require any symbols to be     exported, it is possible to combine -flto and -fwhopr with -fwhole-program to allow the interprocedural optimizers     to use more aggressive assumptions.

  

最后一条值得注意，也许 LDFLAGS 可以添加一个常驻选项。

http://gcc.gnu.org/wiki/LinkTimeOptimization
看起来，类似 gcc-4.2 到 gcc-4.3 的转变，需要添加一个支持库 libelf。
http://www.mr511.de/software/

聚焦深空

http://gcc.gnu.org/wiki/LinkTimeOptimization

Requirements

The fundamental mechanism used by the compiler to delay optimization until link time is to write the GIMPLE representation of the program on special sections in the output file. We have chosen ELF as the container format for these sections, so in order to use LTO the target must support ELF. We are using libelf v0.8.12, but any relatively recent libelf implementation should work. Note that ELF is only required as the container format for GIMPLE, this does not mean that ELF must be used as the final executable format.
Despite the "link time" name, LTO does not need to use any special linker features. The basic mechanism needed is the detection of GIMPLE sections inside object files. This is currently implemented in collect2.  Therefore, LTO will work on any linker already supported by GCC.
As an added feature, LTO will take advantage of the plugin feature in gold. This allows the compiler to pick up object files that may have been stored in library archives. To use this feature, you must be using gold as the linker and enable the use of the plugin by compiling with gcc -use-linker-plugin.  This will shift the responsibility of driving the final stages of compilation from collect2 to gold via the linker plugin.

=> http://sourceware.org/ml/binutils/2008-03/msg00162.html

To build it, configure with --enable-gold.  You will then get gold
instead of the usual GNU ld.

gold is written in C++.  It is likely that it only works with gcc
version 4.0 or later.  I would be happy to apply simple compatibility
patches for earlier versions.

gold only supports ELF targets such as GNU/Linux and other free
operating systems.  gold does not support Windows.  There is no
expectation that gold will ever support anything other than ELF
targets.

At the moment gold only supports x86 and x86_64 targets.  It is
designed for portability, and we expect to add support for more
targets in the future.

At the moment gold has only one significant advantage over the
existing linker: it is faster.  On large C++ programs, I have measured
it as running five times faster.

一向不喜欢基于 c++ 的软件包，也许该改变了。