首页 > 代码库 > Upgrading Compilers on CentOS
Upgrading Compilers on CentOS
这篇日志应该叫「六美分历险记」的,「六美分」顾名思义嘛,自然是指CentOS-6。
下面扯扯为何对本屌来说是「历险」和为虾米要「历险」: 偶对red hat系的向来无爱。当偶还是linux小白时,就曾在虚拟机里折腾过高大上的fedora,没用过多久就遇到了kernel panic啊有木有!差点把小白吓退散了有木有! 后来很长一段时间都是随大众用Ubuntu,接触了Debian系的dpkg就果断和rpm阵营分道扬镳啊,直到又重新折腾起「中立邪恶」的Arch,现在玩的是非主流的吃豆人(pacman)——还是能把系统滚死的吃豆人哦,刺激吧XD。 在Arch的蛊惑下,偶走向了「追新」的sb之路,不隔三差五来一次upgrade享受之后「咦,居然没挂」的快感简直就像少了什么——何弃疗。 阔素捏,实验室的机器偏偏全是六美分,服务器嘛,要稳定才是王道,这偶也素明事理滴(想起前几天看到知乎某问题,Arch党表示躺中啊XD)。 但是……本屌一看gcc还是4.4.7就不爽啊,package要老至少也要对c++11支持好点吧……于是一不做二不休,发挥在Arch下折腾的本事,手动更新gcc,顺带把clang也装上。
tmux
在折腾gcc和clang之前,偶先把好用的tmux装上。 结果yum install tmux
后六美分就抱怨装不上了, 于是偶直接源代码安装省事。 执行tmux又跑不起来,说是找不到libevent
的动态链接库。 「这坑爹的」偶暗暗咒骂了句,继续源代码安装libevent-2.0.21-stable。 我执行
1
|
|
查看了下这个系统路径,在执行libevent的configure
时加上--prefix=/lib
参数把它安装到$LD_LIBRARY_PATH
中的/lib
。tmux
就搞定了。
llvm
接下来先说说装llvm和clang。照着官方文档做还是挺顺的,没有出现什么问题。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
gcc
gcc的安装就没有那么顺了。我装的是4.8.1,一开始执行./configure
就碰到没有GMP、MPFR和MPC这三个库的抱怨。 好在官网的Installing GCC: Prequisites提供了这些库的下载地址,我就去下载源代码编译安装了(用tmux
同时开几个窗口跑真心爽啊XD)。 好吧,这在官方文档中是不推荐的,但偶总觉得比装六美分的rpm要靠谱呢。 其实在./configure
时指定好--prefix=/lib
参数,动态链接库就可以被系统找到了(只要在$LD_LIBRARY_PATH
的都可以)。 倒不用像官方文档中吐嘈的需要在执行gcc的configure
时设置
1
|
|
并修改LD_LIBRARY_PATH
。
接下来就是执行make
了,我遇到了一个错误:
1
|
|
求助万能的StackOverflow,果然找到了答案。把glibc-devel
和libstdc++-devel
这两个软件包装上就行,这次我用的是yum install
。
PS. 我后来查history发现还执行了
1
|
|
不太清楚不装这软件包会不会给gcc的安装带来困扰——折腾党们可以自行尝试XD
后续
用cuda-gdb调试我的程序时host端的函数出现「symbol not found」的问题(我编译时已经加了-g
与-G
参数),运行了以下命令:
1
|
|
六美分又出现了很多类似的抱怨:
1
|
|
把/etc/yum.repos.d/CentOS-Debuginfo.repo
中的enabled=0
改为enabled=1
,再执行一遍debuginfo-install
就可以了。
可是原本的问题依旧存在,于是怀疑是gdb和4.8.1的gcc合不来。 查了下六美分上的gdb版本,是7.2-50.el6,而最新的已经有7.6.1了。 果断继续源代码更新gdb!
奇怪的是,gdb更新完了,cuda-gdb -v
还是显示的7.2:
1 2 3 4 5 6 |
|
我怀疑是cuda-gdb
没绑定到最新版的host端gdb,请教了下实验室的SA大大,她直接帮我重装了CUDA5.5的Toolkit,结果还是不行。查了一下Toolkit的官方文档,5.5还不支持gcc4.8.1,杯具,之前的折腾变成挖坑了……好在我把新版的都装到/usr/local/下,/usr/bin/里面的还是六美分原本的老掉牙版本,没有被覆盖……