众所周知，gcc 是可以多版同存的，因此很多时候为了测试新版 gcc 与及避免对原来系统影响太多的前题下，我会将新的 gcc 装到 /opt 里去（configure 的时候用 --prefix=/opt/gcc-xxx），然後在 /usr/bin 下使用 symlink 方式来切换新旧版，尽管多数情况下都没有换回旧版去。。。
情况是这样的，真正建构系统的 toolchain 是 gcc-4.0.3 （--prefix=/usr，在 /usr/bin 里的），其後 gcc 经历几次升级，於是 /opt 里装了 gcc-4.1.2，gcc-4.2.0 及最新的 gcc-4.2.1
由於 gcc-4.2.1 是 gcc-4.2.x 的 bugfix release，而 gcc-4.2 又比前几代性能优越，加上 gcc-4.2 早已用上多时，因此觉得系统里的旧版 gcc 实在多余，於是便把心一横，决定干掉所有旧版，只留新版。由於用了 paco，谨慎起见，还是用 paco 先打了几个 gcc-xxx-paco.tar.gz 的包才动手
干掉後，只需在 /usr/bin 里建几个对应 /opt/gcc-4.2.1/bin 里的 symlink，包括：
gcc
g++
c++
cpp
gcov
gccbug
i686-linux-pc-xxxx
还有 /lib/cpp 等便行
好了，似乎一切无误，编译程序都正常，可是问题出现了，一些以往能跑的程序如 xpdf、kpdf、kwrite 等等相继服错，说找不到什麽 libgcc_s.so.1，检查一下 /opt/gcc-4.2.1/lib 里是有的，再仔细校对一下，终於知道问题了。原来是干掉原系统里的 gcc-4.0.3 的时候，系统把 /lib/libgcc_s.so.1 也去掉了，形成程序运行时找不到该库而服错，这好办，建一个 symlink 到 /opt/gcc-4.2.1/lib 不就行了？
哈哈，果然揍效，一切回复正常。
这里告诉我们两件事：
1. 在多版 gcc 的情况下，即使程序由新版 gcc 编译出来，它有可能仍在默认的库路径找出旧版 gcc 的库来用，这方面只要稍作修正便行
2. 在非覆盖式安装新版 gcc 的情况下，要注意执行文件的路径及相关的库
后记：
我不是专家，纯绪基於 trial-and-error 得来经验，如有错漏，敬请指正。
