CentOS65从源码编译安装GCC491全程实录《第二部分编译安装测试》.docx
《CentOS65从源码编译安装GCC491全程实录《第二部分编译安装测试》.docx》由会员分享，可在线阅读，更多相关《CentOS65从源码编译安装GCC491全程实录《第二部分编译安装测试》.docx（17页珍藏版）》请在冰豆网上搜索。
CentOS65从源码编译安装GCC491全程实录《第二部分编译安装测试》
刖言
GCC（GNUCompilerCollection,GNU®译器合集）是linux以及其他类UNIX平台上进行开源项目，软件开发等必不可少的工具链组成之一（工具链的其他成员包括
binutils,Glibc,libstdc++等）
另夕卜，对于程序员以及系统管理员而言，经常需要从软件的源码手动编译安装，而不论是configure脚本，还是make工具/makefile文件，最终都需要调用gcc（或者其它编译器）来进行实际的编译工作，因此，经常需要使用gcc的新版特性，
并且与旧版gcc共存，根据实际的需求进行调用。
在本篇博文中，我们以centos6.532位系统上已安装的旧
版gcc二进制可执行文件以及GlibcC库为基础，从网上下载最新版的gcc源码包手动编译安装，进行简单的测试，并且与make工具整合，从configure脚本进行参数传递，优化编译等。
整个过程简单明了，图文代码并茂，希望能起到抛砖引玉的作用，激发广大爱好者编程与学习的热情。
《编
译，安装与测试》
前面我们多次提到：
gcc应该在单独的目录里面进行配置和编译，不要让生成的中间文件污染了源码目录，除非你决定在整个安装过程结束后，删除源码目录和编译目录。
我们使用单独的编译目录compile-dir来存储经由make命
令编译生成的二进制文件，然后用makeinstall命令，将这些文件复制到最终的安装目录：
/usr/local/new-exec-gcc-4.9.1
首先，进入编译目录，在该目录下，以绝对路径的形式调用
gcc源码目录下的configure脚本文件，在其后面指定编译参数，其中：
--prefix=/usr/local/new-exec-gcc-4.9.1/就是上面讲
到的最终安装路径。
--enable-bootstrap这里引用网上一些文献对该参数的解
释：
用第一次编译生成的程序进行第二次编译，然后用再次生成的程序进行第三次编译，并且检查比较第二次和第三次结果的正确性，也就是进行冗余的编译检查工作。
非交叉编译环境下，默认已经将该值设为enable，可以不用显
示指定；交叉编译环境下，需要显示将其值设为disable。
--enable-checking=release以软件发布版的标准来对编译
时生成的代码进行一致性检查；设置该选项为enable并不会
改变编译器生成的二进制结果，但是会导致编译的时间增加；该选项仅支持gcc编译器；
总体而言，对于上面这个选项，机器的硬件配置较低，以及不愿等待太久编译时间的童鞋，可以设置为disable;但是这会
增加产生未预期的错误的风险，所以应该慎用。
可以同时设置--disable-bootstrap与--disable-
checking，这对编译过程的提速很有帮助。
--enable-threads=posix顾名思义，启用posix标准的线
程支持
要让程序能在符合POSIX规范的linux发布版上正确运行，就应该启用该选项，取决于宿主或目标操作系统的类型，其它可用值有：
aix，dec，solaris，win32等，如果你是其它的类UNIX系统，就需要设置相应的值。
--enable-languages=c,c++
支持的高级语言类型和运行时库，可以设置的所有语言包括ada,c,c++,Fortran,java,objc,obj-c++,GO等语言。
这里只开
启了c和c++,因为支持的语言越多，就需要安装越多的相应静态与动态库，还有五花八门的依赖库，这会让管理变得困难，体积也会变得庞大。
--disable-multilib很多文章对这个参数的解释让人摸
不着头脑。
简单的讲，如果你的操作系统是32位，默认就已经
设置为disable，这意味着gcc仅能生成32位的可执行程序；如果你的操作系统是64位，默认就已经设置为enable，这意味着用gcc编译其它源文件时可以通过-m32选项来决定是否
生成32位机器代码。
如果在64位系统上，要禁止生成32位代码，设置--
disable-multilib。
--enable-gather-detailed-mem-stats
允许收集详细的内存使用信息，如果设置该参数为enable，则
将来编译好的gcc可执行程序，可以通过-fmem-report选项来输出编译其它程序时的实时内存使用情况。
--with-long-double-128
指定longdouble类型为128位（16字节！
）；设置为
without，贝Ulongdouble类型将为64位（8字节），这将与
普通的double类型一样。
基于Glib2.4以上版本编译时，默认已经是128位。
1[root@centos6-5vm桌面]#cd/extracted-src-dir/gcc-4.9.1/
2[root@centos6-5vmgcc-4.9.1]#cd/compile-dir/
3[root@centos6-5vmcompile-dir]#pwd
4/compile-dir5[root@centos6-5vmcompile-dir]#/extracted-src-dir/gcc-
4.9.1/configure--prefix=/usr/local/new-exec-gcc-4.9.1/--enable-
bootstrap--enable-checking=release--enable-threads=posix--
enable-languages=c,c++--enable-gather-detailed-mem-stats-with-
long-double-128
如果以上面给出的参数集来运行configure脚本，会
在compile-dir目录下生成
config」og，config.status，Makefile，serdep.tmp四个文
件，用gedit或者其它文本编辑器打开config.log，以error
为关键字符串，搜索configure检测到的潜在配置错误和警
告，这对后面的make阶段能否正常编译至关重要：
如果没有任
何与error相关的警告信息，那么就认为可以执行make命
令。
在当前工作目录下，执行make命令来启动编译进程，整个编译过程花费的时间很大程度上取决于你的系统硬件配置，以及指定给configure脚本的参数，
我的硬件配置如下，大概也花了近40分钟才编译完成：
a-AH
[FDEIttCflntl-Sl-5Afl]tlEPtiIIFfDSATA
l«:
1f,2HTAcmiirtrtller:
IntelUriporttU>t$crit>/C21«ScriesCfeiputfwitvI-portSATL**、、
在此基础上，我用下面的命令来加速编译过程，其中-j指定
同时开启的进程数，要充分发挥多核处理器的并行执行优势，这个值应该是处理器芯片上物理核心的2倍。
根据测试，上面
的硬件配置并行执行8个进程编译，大约20分钟多一些就编译完成了，所以，CPU要给力才行。
1[root@centos6-5vmcompile-dir]#make-j8
另外，如果在make中途出错退出，应该执行下面指令清空
compile-dir目录下的相关文件，包括makefile，
1[root@centos6-5vmcompile-dir]#makedistclean
然后根据错误提示修改传递给configure脚本的参数，或者安装相关依赖库，支持包等等，重新运行configure脚本，检查config.log文件的内容，最后再次执行make命令。
执行下面的命令将编译好的可执行文件，库文件等，从
compile-dir复制至U
/usr/local/new-exec-gcc-4.9.1/目录下面，完成最后的安
装。
LibrarSeshavebeeaInstilliHiin:
/WAwV—MBK4SC>4.1.l/l.|b
如果你的硬盘空间比较吃紧，或者有良好的磁盘清理习惯，那
么不妨删除compile-dir以及extracted-src-dir目录中的内容，并且备份downloaded-src-dir目录中的所有6个源
码包，日后有需要时可以再次从源码编译安装。
《
测试，优化，整合make,新旧版本gcc共存》
为了方便后面的测试以及与make的整合，我们先用符号链接的方式，实现新旧版本gcc共存系统上，按需调用。
常规情况下，要用新版gcc来编译C源文件或用其它高级语言编写的源文件，需要以
/usr/local/new-exec-gcc-4.9.1/bin/gcc
这种绝对路径的形式来调用，如果仅输入命令gcc，则shell
会调用旧版的gcc，也就是/usr/bin/gcc下的gcc，这是因为
新版的gcc可执行文件所在绝对路径还没有加入shell的命令
搜索路径中，而搜索路径是一种环境变量，因此按理讲应该将其加入环境变量，但是这样就会覆盖原有的gcc，或者产生歧
义，shell无法判断用户的意图是要使用那一个。
使用符号链接的方案可以避免上述问题。
依旧是先确定一下旧版gcc的可执行文件所在路径：
bin]#cd/
/]#whichgcc
/]#whereisgcc
/usr/lib/gcc/usr/libexec/gcc
进入/usr/bin目录，创建一个指向新版gcc可执行文件所在
路径的符号链接，记得要同时创建新版g++的相应链接:
1
[root@centos6-5vm/]#cd/usr/bin
2
[root@centos6-5vmbin]#pwd
3
/usr/bin
4
4.9.1/bin/g++new-g++4-9-1
如此一来，shell还是搜索/usr/bin下的可执行文件，但是
根据用户输入的命令来调用相应的文件，例如，用户输入
gcc，则调用/usr/bin/gcc，用户输入new-gcc-4-9-1，则调
用相应符号链接指向的原始文件。
下面的截图验证了这一部分讲述的内容：
再次确认:
接下来，需要将新版gcc的库文件安装路径，添加到“库的搜索路径”（LD_LIBRARY_PATH这个环境变量中，日后链接器就会使用新添加的库路径中的动态库以及启动文件，来链接经由汇编器生成的目标文件，前面在makeinstall结束时，系统也
给出了类似的提示信息（参考前面的截图）：
1[root@centos6-5vm桌面]#vim/etc/profile
向文件中添加以下内容，并且保存退出
1#toaddthelibrariesofnewversiongcc4.9.1tothee
nvironmentvariable
2
exportLD_LIBRARY_PATH="/usr/local/new-exec-gcc-4.9.1/lib"
需要重启系统，配置项才会生效，要立即生效而不重启，执行
下面的命令：
1[root@centos6-5vmetc]#source/etc/profile
对/etc/profile文件内容的改动将影响系统中的所有用户以
及包括bashshell在内的常用shell，这意味着，在进行团队协作软件开发，结对编程时，上面的设置能确保使用各自用户账户登录系统的程序员能在开发过程中共享新添加的库，还
可以避免因为链接到的库不一致而产生冲突。
此后，我们可以立即执行下面的命令来打印并输
出$LD_LIBRARY_PAT的当前值，从而验证上面讲到的相关内容：
1[root@centos6-5vm桌面]#echo$LD_LIBRARY_PATH
2/usr/local/new-exec-gcc-4.9.1/lib
顺便一提，如果你使用类似下面的命令来直接在当前开启的
shell设置LD_LIBRARY_PATH环境变量，那么：
1.关闭shell后，所做的更改将会丢失，往后需要再次添加
2.登出X-window，使用其它账户登入，需要再次添加
3.系统重启后，需要再次添加
1[root@centos6-5vm/]#declare-
xLD_LIBRARY_PATH="/usr/local/new-exec-gcc-4.9.1/lib"
新版gcc与makeconfigure配置脚本的协作编译》
现在，可以通过新版本的gcc来编译单独的C/C++源文件，但
是对于大型的开源项目，其中有成百上千个源文件，不可能手动一个个编译，幸好成体系的软件项目都带有configure脚
本，可以显式给configure脚本指定要使用的编译器，这是通
过向configure脚本传递环境变量CC来实现的，而CC的值可以在传递给configure前临时定义，详情容后再作介绍
因为有些中小型项目的源码包里面没有提供configure脚本，
因此如果不在configure阶段指定编译器，那么在其后的make
阶段指定也行，因为make也读取CC的值来判断要使用那种编译器：
1[root@centos6-5vm桌面]#make-p|grepCC
2make:
***没有指明目标并且找不到makefile。
停止。
3LINK.0=$（CC）$（LDFLAGS）$（TARGET_ARCH）
4CC=cc
5CPP=$（CC）-E
1
[root@centos6-5vm桌面]#make-p|grepCXX
2
make:
***没有指明目标并且找不到makefile。
停止。
3
4LINK.cc=$（CXX）$（CXXFLAGS）$（CPPFLAGS）$（LDFLAGS）$（TARGET_A5RCH）
COMPILE.cc=$（CXX）$（CXXFLAGS）$（CPPFLAGS）$（TARGET_ARCH）-c
CXX=g++
可以看到，make默认使用CC作为C编译器；使用CXX作为
C++编译器。
而cc是/usr/bin下的符号链接，它就指向/usr/bin下的旧
版gcc编译器:
我们需要将cc指向新安装的gcc的二进制可执行文件。
在这之前，先删除掉系统原来创建的到旧版gcc的链接:
」root@centos6-5vm
桌面］#
cd
/usr/bin
2[root@centos6-5vm
bin]#
rm
-fcc
3[root@centos6-5vm
bin]#
In
-s/usr/local/new-exec-gcc-
4.9.1/bin/gcc
cc
再次查看cc的属性，确认变更已经生效:
还记得前面我们将自定义名称的新版编译器（new-gcc-4-9-1）
链接到同一个二进制可执行文件吗:
工具只会使用CC，因此修改cc指向的程序来让make调用新版的gcc编译软件源码就显得尤为重要。
F面这张截图验证了上面我们的劳动成果:
另一种办法是，从make的配置输出可知，cc的值赋给了环境
变量CC因此直接把cc用新版的gcc编译器的绝对路径替换
掉也可以：
修改/home/[user]/.bashrc文件（单次修改永久有效，但
仅对该用户账户的shell环境有效）；
例如，当前用户是root,执行命令su-shayi,将shell环境和用户都切换到shayi，执行make-p|grepCC，在输出中可以看到，CC=cc
然后启动vim修改/home/shayi/.bashrc，在其中添加
exportCC="/usr/local/new-exec-gcc-4.9.1/bin/gcc"
保存退出，在当前shell执行exit，退出shayi用户，回到root用户，再次执行
make-p|grepCC,在输出中看到CC=cc,因为修改shayi
的bashrc仅仅影响shayi用户的环境变量，
再次执行su-shayi，将shell环境和用户切换到shayi,执行make-p|grepCC，可以看到，
CC=/usr/local/new-exec-gcc-4.9.1/bin/gcc，所做的变更
已经在退出该用户并且重新登录后生效。
或者系统级别的全局配置文件/etc/profile（单次修改永久
有效，而且对包括root超级用户在内的所有系统中的账户的shell环境均有效）
在文件中添加下面2行内容，：
〔exportCC="/usr/local/new-exec-gcc-4.9.1/bin/gcc"
2exportCXX="/usr/local/new-exec-gcc-4.9.1/bin/g++"
本段小结：
通过修改make数据库中定义的和C编译器相关的符号链接，或者环境变量，我们实现了新版gcc与make协作，自动“批量”编译项目中的C源文件。
而且，往后需要让make调用旧版gcc批量编译时，只需将相关的符号链接，或者环境变量，替换成旧版gcc的可执行文件所
在路径就可以了。
这赋予软件开发人员以及程序员极大的灵活性，真正做到了自动化按需调用。
升级会员 