1、简介      GCC（GNU Compiler Collection，GNU编译器套件），是由 GNU 开发的编程语言编译器。它是以GPL许可证所发行的自由软件，也是 GNU计划的关键部分。GCC原本作为GNU操作系统的官方编译器，现已被大多数类Unix操作系统（如Linux、BSD、Mac OS X等）采纳为标准的编译器，GCC同样适用于微软的Windows。官方链接：http://gcc.gnu.org/       类别：编译器2、基础环境类别子项版本获取地址(方法)华为云虚拟机RC3（916）--OSCentOS7.5  Kernel4.14 软件包Gcc4.8.5 3、依赖安装无4、组件编译安装在yum源中查找gcc列表yum list|grep gcc在yum源直接安装gccyum install gcc5、系统配置无6、测试测试内容：gcc是否能正常使用1）vim test.ctest.c编辑内容为：#include <stdio.h>int main(int argc,char * argv[]){puts("Hello Arm!");return 0;}2）gcc test.c -o test3）./test测试结果：7、参考信息官方文档：https://gcc.gnu.org/onlinedocs/ 8、FAQ无

1.   简介GCC 编译器是 Linux 下默认的 C/C++ 编译器，大部分 Linux 发行版中都是默认安装的。GCC 编译器通常以 Linux 命令的形式在终端（Shell）中使用。本指南描述了在ARM64，CentOS7.5的环境下升级GCC的过程，可供相关人士参考。2.   部署环境Packet NameVersionCentOSCentOS  7.5 with ArmGCC5.4.07.3.03.   安装部署      3.1  编译升级GCC由于服务器Centos7.5默认安装的GCC版本较低，在某些场景下需要进行升级GCC，版本信息如下：[root@ecs-arm-felix-free01   ~]# gcc --versiongcc   (GCC) 4.8.5去官网下载http://ftp.gnu.org/gnu/gcc/下载GCC 5.4.0的源码压缩包解压安装       解压gcc-5.4.0.tar.gz[root@ecs-arm-felix-free01   ~]# tar -xvf gcc-5.4.0.tar.gz下载安装依赖,下载安装gcc需要的三个依赖[root@ecs-arm-felix-free01   ~]# yum -y install bzip2 wget    # 下载依赖需要使用把bzip2和wget两个命令[root@ecs-arm-felix-free01   ~]# cd gcc-5.4.0/[root@ecs-arm-felix-free01   ~]# ./contrib/download_prerequisites  #   在解压根目录中执行依赖下载完成后，编译更新gcc版本 [root@ecs-arm-felix-free01   ~]# cd ../ && mkdir gcc-build-5.4.0 && cd gcc-build-5.4.0    #执行命令前位于gcc-5.4.0目录下#   执行configure[root@ecs-arm-felix-free01   ~]# ../gcc-5.4.0/configure --enable-checking=release --enable-languages=c,c++   --disable-multilib#   执行编译，make时间1-2小时或更久[root@ecs-arm-felix-free01   ~]# make -j8    #-j8意味8核并行编译；[root@ecs-arm-felix-free01   ~]# make install    #执行安装备注：如果执行过程遇到configure: error: C++ preprocessor "/lib/cpp" fails sanity check，执行[root@ecs-arm-felix-free01   ~]# yum install glibc-headers [root@ecs-arm-felix-free01   ~]# yum install gcc-c++验证是否更新生效[root@ecs-arm-felix-free01   ~]# gcc -versiongcc   (GCC) 5.4.0生成的动态库替换老版本gcc的动态库。[root@ecs-arm-felix-free01   ~]# cp /usr/local/lib64/libstdc++.so.6.0.21 /lib64 [root@ecs-arm-felix-free01   ~]# cd /lib64 & cp libstdc++.so.6 libstdc++.so.6.old[root@ecs-arm-felix-free01   ~]# ln -s libstdc++.so.6.0.21 libstdc++.so.6#执行命令查看最新GLIBCXX_3.4.21[root@ecs-arm-felix-free01   ~]# strings /lib64/libstdc++.so.6 | grep GLIBC    3.2 参考信息     [1] GCC升级版本：https://www.linuxidc.com/Linux/2018-11/155395.htm

GCC官网编译选项网址：https://gcc.gnu.org/onlinedocs/gcc/Option-Index.html#Option-Index也可以去gcc源码中查询通用编译选项在gcc/common.opt中各个后端独有的在config/XXX/XXX.opt；例如gcc/config/arm/arm.opt查看各个优化默认的编译选项：gcc -c -Q -O3 --help=optimizersgcc -c -Q -O2 --help=optimizersgcc -c -Q -Os --help=optimizers

gcc 语言编译全过程：预处理->编译->汇编->链接一、GCC快速入门Gcc指令的一般格式为：Gcc [选项] 要编译的文件 [选项] [目标文件]其中，目标文件可缺省，Gcc默认生成可执行的文件名为：a.out我们来看一下经典入门程序"Hello World！"# vi hello.c#include <stdlib.h>#include <stdio.h>void main(void){printf("hello world!\r\n");}用gcc编译成执行程序。#gcc hello.c该命令将hello.c直接生成最终二进制可执行程序a.out这条命令隐含执行了（1）预处理、（2）汇编、(3)编译并(4)链接形成最终的二进制可执行程序。这里未指定输出文件，默认输出为a.out。如何要指定最终二进制可执行程序名，那么用-o选项来指定名称。比如需要生成执行程序hello.exe那么#gcc hello.c -o hello.exe二、GCC的命令剖析--四步走从上面我们知道GCC编译源代码生成最终可执行的二进制程序，GCC后台隐含执行了四个阶段步骤。GCC编译C源码有四个步骤：预处理-----> 编译 ----> 汇编 ----> 链接现在我们就用GCC的命令选项来逐个剖析GCC过程。1）预处理(Pre-processing)在该阶段，编译器将C源代码中的包含的头文件如stdio.h编译进来，用户可以使用gcc的选项”-E”进行查看。用法：#gcc -E hello.c -o hello.i 作用：将hello.c预处理输出hello.i文件。[root]# gcc -E hello.c -o hello.i[root]# lshello.c  hello.i[root]# vi hello.i# 1 "hello.c"# 1 "<built-in>"# 1 "<command line>"# 1 "hello.c"# 1 "/usr/include/stdlib.h" 1 3# 25 "/usr/include/stdlib.h" 3# 1 "/usr/include/features.h" 1 3# 291 "/usr/include/features.h" 3# 1 "/usr/include/sys/cdefs.h" 1 3# 292 "/usr/include/features.h" 2 3# 314 "/usr/include/features.h" 3# 1 "/usr/include/gnu/stubs.h" 1 3# 315 "/usr/include/features.h" 2 3# 26 "/usr/include/stdlib.h" 2 3# 3 "hello.c" 2void main(void){printf("hello world!\r\n");}2)编译阶段(Compiling)第二步进行的是编译阶段，在这个阶段中，Gcc首先要检查代码的规范性、是否有语法错误等，以确定代码的实际要做的工作，在检查无误后，Gcc把代码翻译成汇编语言。用户可以使用”-S”选项来进行查看，该选项只进行编译而不进行汇编，生成汇编代码。选项 -S用法：[root]# gcc –S hello.i –o hello.s 作用：将预处理输出文件hello.i汇编成hello.s文件。[root@richard hello-gcc]# lshello.c  hello.i  hello.s如下为hello.s汇编代码[root@richard hello-gcc]# vi hello.s.file   "hello.c".section    .rodata.LC0:.string "hello world!\r\n".text.globl main.type   main,@functionmain:pushl   %ebpmovl    %esp, %ebpsubl    $8, %espandl    $-16, %espmovl    $0, %eaxsubl    %eax, %espsubl    $12, %esppushl   $.LC0call    printfaddl    $16, %espmovl    $0, %eaxleaveret.Lfe1:.size   main,.Lfe1-main.ident  "GCC: (GNU) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)"3)汇编阶段(Assembling)汇编阶段是把编译阶段生成的”.s”文件转成二进制目标代码.选项 -c用法：[root]# gcc –c hello.s –o hello.o 作用：将汇编输出文件test.s编译输出test.o文件。[root]# gcc -c hello.s -o hello.o[root]# lshello.c  hello.i  hello.o  hello.s4）链接阶段(Link)在成功编译之后，就进入了链接阶段。无选项链接用法：[root]# gcc hello.o –o hello.exe 作用：将编译输出文件hello.o链接成最终可执行文件hello.exe。[root]# lshello.c  hello.exe  hello.i  hello.o  hello.s运行该可执行文件，出现正确的结果如下。[root@localhost Gcc]# ./helloHello World!在这里涉及到一个重要的概念：函数库。读者可以重新查看这个小程序，在这个程序中并没有定义”printf”的函数实现，且在预编译中包含进的”stdio.h”中也只有该函数的声明，而没有定义函数的实现，那么，是在哪里实现”printf”函数的呢？最后的答案是：系统把这些函数实现都被做到名为libc.so.6的库文件中去了，在没有特别指定时，gcc会到系统默认的搜索路径”/usr/lib”下进行查找，也就是链接到libc.so.6库函数中去，这样就能实现函数”printf” 了，而这也就是链接的作用。你可以用ldd命令查看动态库加载情况：[root]# ldd hello.exelibc.so.6 => /lib/tls/libc.so.6 (0x42000000)/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)函数库一般分为静态库和动态库两种。静态库是指编译链接时，把库文件的代码全部加入到可执行文件中，因此生成的文件比较大，但在运行时也就不再需要库文件了。其后缀名一般为”.a”。动态库与之相反，在编译链接时并没有把库文件的代码加入到可执行文件中，而是在程序执行时由运行时链接文件加载库，这样可以节省系统的开销。动态库一般后缀名为”.so”，如前面所述的libc.so.6就是动态库。gcc在编译时默认使用动态库。 

GCC安全编译选项具体可以参考这份博客：https://www.cnblogs.com/fengbeihong/p/3641384.html

Short Table of Contents1 Programming Languages Supported by GCC2 Language Standards Supported by GCC3 GCC Command Options4 C Implementation-Defined Behavior5 C++ Implementation-Defined Behavior6 Extensions to the C Language Family7 Extensions to the C++ Language8 GNU Objective-C Features9 Binary Compatibility10 gcov—a Test Coverage Program11 gcov-tool—an Offline Gcda Profile Processing Tool12 gcov-dump—an Offline Gcda and Gcno Profile Dump Tool13 Known Causes of Trouble with GCC14 Reporting Bugs15 How To Get Help with GCC16 Contributing to GCC DevelopmentFunding Free SoftwareThe GNU Project and GNU/LinuxGNU General Public LicenseGNU Free Documentation LicenseContributors to GCCOption IndexKeyword Index

https://baike.baidu.com/item/gcc/17570?fr=aladdin

本帖最后由 霁月 于 2018-2-1 15:55 编辑我们解决什么问题？先设想一个场景：你熬夜写完了论文，终于觉得可以喘一口气，然后舒舒服服地按下了CTRL+S保存文件。就在这时，你家的猫大爷拔掉了你的电源，你的文件还在吗(图片来自网络)？你肯定会想：这软件那么多用户，那么多专业的程序员，肯定没事吧？最多就是我最后没保存的几个错别字没改过来呗。这可不一定哦！这个问题更学术一点的定义叫“崩溃一致性(crash consistency)”。这个概念最早出现在文件系统的研究中——文件系统是一个庞大的数据结构，而一个文件操作通常需要对数据结构的多个部分进行修改，因此在诸如断电、系统故障等情况下保持文件系统的一致性就成为了一个挑战。崩溃一致性的基本概念在Remzi的经典教科书“Operating Systems: Three Easy Pieces”[2]中可以找到。之前的研究工作表明，无论是SSD硬件[3]、数据库系统[4]还是系统软件[5]，在现有的文件系统实现(ext4, btrfs, NTFS, ...)上多少都有一些崩溃一致性的问题。连那么厉害的专业程序员、久经考验的开源和商业项目都没搞定的事情，想必遍地的新手程序员们也会犯类似的错误吧(在读完宗师大佬们的文章以后，我的内心就是这么想的)？你猜对了。事实是，你的文本编辑器真的有可能摧毁你的文件。不仅文本编辑器有这个问题，相当多的其他类型的应用软件也存在这个问题。我们的论文就解决一个问题：让检测应用程序崩溃一致性bug的过程尽量简单，简单到只要按一个键就可以了。从一个Bug例子说起我是一名苦逼的程序员，为了养家糊口在外包公司做一个文本编辑器的项目。今天我完成的功能是存盘，在按下存盘键以后，将打开的文件保存。小case，我在Stackoverflow上搜索了“Java write file”，然后搞到了如下(简化的)代码：voidwriteTextFile(Stringpath,Stringcontent){PrintWriterwriter=newPrintWriter(path);writer.write(content);writer.close();}作为一名优秀的程序员，我想了想这样好像不太对……万一在write的时候出了什么状况，用户的文件不就丢了么？所以最好先做个备份，肯定就万无一失了。于是我把代码改成了下面这样，跑完测试就愉快地回家逗猫玩了。voidsafelyWriteTextFile(Stringpath,Stringcontent){backupPath=path+".tmp";writeTextFile(backupPath,content);deleteItem(path);renameItem(backupPath,path);}然而事情没那么简单。POSIX说，你确实是按照open -> write -> delete -> rename的顺序执行了操作，但我才没有规定从文件系统的角度看，它们是按照你执行的顺序完成的呢！什么？这意味着……如果系统偷偷调换write和delete操作的顺序，并且在删除操写入磁盘后立即断电，那不就等于把用户的文件给删掉了么？也就是说，如果猫大爷真的在保存文件的时候拔掉了电源，这文件整个就没了啊(论文就没有了啊喂)！更可怕的是，现在的文件系统(比如默认设置下的ext4)因为只保留了元数据的日志而没有保存数据操作的日志，这样的“乱序”是真正能被观察到的[5, 6]！这段代码来自文本编辑器Ted，所幸的是这个bug成功地被我们的工具检测到。崩溃一致性的自动检测现在我们有足够的动机去做一个工具检测应用程序的崩溃一致性了。对于程序猿来说，最好的工具就是拿来就能用的工具。所以我们的工具Crash Consistency Checker (C3)只需要被测程序的可执行文件和一个测试用例，方法大致分为3步(对技术细节没有兴趣的可以直接跳过)：[*]运行一遍程序，取得我们认为对于应用来说“正确”的文件系统快照。什么是“正确”的快照呢？我们认为程序猿不会傻傻地把重要的用户文件删掉。所以，我们认为所有元数据操作执行完毕后，内存中的文件系统快照代表了程序猿定义的“正确”状态。实现上，我们用ptrace拦截程序发出的系统调用，并在系统调用结束后从内存中抓取快照。回到之前保存文件的例子，“正确”的快照中至少包含一个文件的内容。 [*]使用一个虚拟的磁盘捕获所有的I/O请求，然后生成可能的崩溃现场。这个技术和已有的技术[4,5,6]十分类似。实现上，我们写了一个ramdisk的驱动，它从外面看表现得和正常的磁盘一模一样，但在后台悄悄记录了所有I/O操作的内容。根据这些I/O操作，就可以生成在Linux设备驱动规约允许条件下的各种崩溃现场。对于之前保存文件的例子，我们将会得到原文件被删除、备份文件尚未写入的一个文件系统快照。[*]对每个崩溃现场计算与“正确”文件系统快照的编辑距离，如果距离很大，那这个崩溃现场就看起来很可疑。两个文件系统快照的编辑距离定义为通过连续内容的删除/移动/重命名操作将一个快照变为另一个的最小次数。不过直接计算这个编辑距离是NP-Complete的，我们用了一些小技巧做了一个近似，求解一个它的下界(我才不会告诉你最后就是给你两个数组A和B，判断能不能把A里删掉一些元素重排以后变成B，现在小学生都会做这个题啦！)。显然，对于一个没有任何数据的文件系统快照，是无法通过编辑操作变成一个有数据的“正确”快照的，自然就被报告为可疑的bug了。实验结果我们从两大类(命令行工具和生产力工具)挑选了总共25个应用，并对每个应用的一个简单测试用例进行了测试，测试软件在ext4默认设置下的崩溃一致性。结果是我们找到了14个崩溃一致性bug，其中11个是开发者先前未知的bug，让我们看一看：列举一些有代表性的bug：[*]对in-place的处理很容易出错。比如sort F -o F、用于兼容古老版本的功能就变成了有危险的操作，提供原地替换的perl也有类似的问题。[*]gzip和bzip2犯了和之前例子类似的错误：在删除旧文件之前没有等待数据同步，从而导致了“压缩等于删除”的可能。各类生产力工具所犯的错误五花八门，保存文件的方式也各不相同，但很多都导致了同样的后果——数据丢失。[*]最后，gmake的问题在于，在你运行的脚本(如gcc)崩溃后，目标文件的时间戳被更新，内容却损坏了，这样如果这个文件最后被直接打包，就可能会导致严重的后果。虽然说这可以算是gcc的问题，但(1) gcc并不必须要提供崩溃一致性，而且(2) 这个问题最终影响gmake的用户，我们觉得让gmake的用户知道这件事可能发生是很重要的。在惊讶于这么多程序都有这类bug的同时，我们也对剩下通过测试的应用提出表扬，比如著名的Vim和Emacs。最后的提醒 [*]小心处理你的文件。看了这么多血淋淋的例子，我想你以后在保存数据的时候也会格外小心了吧。[*]库函数的支持非常重要。在和开源社区交互的过程中，我们很高兴地看到很多库都开始提供安全的文件操作(例如Qt中的QSaveFile和GTK中的g_file_replace)。与此同时，更多的新兴平台则做得不够好。比如Atom的开发者意识到了这类bug (而且真的有人在使用中触发了这个bug)，但Node.js的系统库却缺乏可移植的方案让他们能更好地避免这种问题。[*]留意崩溃一致性问题。gmake的例子警示我们，崩溃一致性问题不仅是那些保存数据的人需要关心的，也许哪天就悄悄地影响了你。所以如果你觉得这篇文章很有趣，请转发它让更多的人能意识到这个问题的存在。参考文献[1] Y Jiang, H Chen, F Qin, C Xu, X Ma, J Lu. Crash consistency validation made easy. InProceedings of the Symposium on the Foundations of Software Engineering(FSE), 133--143, 2016.[2] R H Arpaci-Dusseau, A C Arpaci-Dusseau.Operating Systems: Three Easy Pieces(v0.91), Arpaci-Dusseau Books, 2015.[3] M Zheng, J Tucek, F Qin, M Lillibridge. Understanding the robustness of SSDS under power fault. InProceedings of the USENIX Conference on File and Storage Technologies(FAST), 271--284, 2013.[4] M Zheng, J Tucek, D Huang, F Qin, M Lillibridge, E S Yang, B W Zhao, S Singh. Torturing databases for fun and profit. InProceedings of the Conference on Operating Systems Design and Implementation(OSDI), 449--464, 2014.[5] T S Pillai, V Chidambaram, R Alagappan, S Al-Kiswany, A C Arpaci-Dusseau, R H Arpaci-Dusseau. All file systems are not created equal: On the complexity of crafting crash-consistent applications. InProceedings of the Conference on Operating Systems Design and Implementation(OSDI), 433--448, 2014.[6] J Yang, C Sar, D Engler. EXPLODE: A lightweight, general system for finding serious storage system errors. InProceedings of the Conference on Operating Systems Design and Implementation(OSDI), 131--146, 2006.原文转载自：https://zhuanlan.zhihu.com/p/25188921

工具介绍STREAM为业界公认的内存性能测试工具，项目地址为http://www.cs.virginia.edu/stream/。主要用于测试CPU访问内存的带宽，代码有C语言和FORTRAN语言两种版本。测试说明：本指导以C语言下的v5.10版本为例，说明如何在CentOS 7.2操作系统下使用STREAM测试弹性云服务器内存性能。测试步骤：1、 获取源文件访问http://www.cs.virginia.edu/stream/FTP/Code/网站，获取stream.c文件，把文件拷贝至弹性云服务器中。2、 编译程序使用gcc编译源文件。如果弹性云服务器中未安装gcc，请先安装gcc程序。按以下命令编译stream.c文件。（注：编译参数仅供参考）69393、 执行程序执行命令./stream运行程序进行测试，执行结果如下图所示，为避免单次执行误差，建议执行5次以上，取平均值。6913

[color=rgb(51,51,51)]在 Linux Plumbers Conference 会议上，Google 的内核开发者 Greg Kroah-Hartman 和 Nick Desaulniers 介绍了用 Clang 构建内核的进展。[color=rgb(51,51,51)]Desaulniers 称今天的 Android 用户空间都用 Clang 构建，Google 想要减少它需要支持的工具链数量，至少在目前用 Clang 构建内核主要对 Google 有利，但有理由相信这对更广泛的社区同样有利。[color=rgb(51,51,51)]Clang 提供了一组与 GCC 不同的警告，更少的 bug 显然对所有内核用户都有利。Clang 还能提高额外的工具，如控制流分析，link-time optimization， profile-guided optimization。用不同的编译器构建代码也有助于筛选出依赖于未定义行为的代码。[color=rgb(51,51,51)]Greg Kroah-Hartman 称竞争对每个人都有利，过去五年 GCC 引入的新特性都是与 LLVM/Clang 竞争的结果。他希望 Linux 内核也有竞争对手。开源中国（来源）​

[code][root@hwclouds-ecs-100 ~]# gcc --versiongcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)Copyright © 2015 Free Software Foundation, Inc.[/code]本程序是自由软件；请参看源代码的版权声明。本软件没有任何担保； 包括没有适销性和某一专用目的下的适用性担保。 [code][root@hwclouds-ecs-100 ~]# yum install -y libmpc-devel mpfr-devel gmp-devel zlib-devel cmake [root@hwclouds-ecs-100 ~]# mkdir -p /tmp/gcc && cd /tmp/gcc [root@hwclouds-ecs-100 /tmp/gcc]# curl -Lk ftp://ftp.gnu.org/pub/gnu/gcc/gcc-5.4.0/gcc-5.4.0.tar.gz|tar xz -C /tmp/gcc --strip-components=1 [root@hwclouds-ecs-100 /tmp/gcc]# ./configure --with-system-zlib --disable-multilib --enable-languages=c,c++ [root@hwclouds-ecs-100 /tmp/gcc]# make -j$(getconf _NPROCESSORS_ONLN) && make install [root@hwclouds-ecs-100 /tmp/gcc]# reboot [root@hwclouds-ecs-100 ~]# gcc --version gcc (GCC) 5.4.0 Copyright © 2015 Free Software Foundation, Inc.[/code] 本程序是自由软件；请参看源代码的版权声明。本软件没有任何担保； 包括没有适销性和某一专用目的下的适用性担保。 [code][root@hwclouds-ecs-100 ~]# g++ --version g++ (GCC) 5.4.0 Copyright © 2015 Free Software Foundation, Inc.[/code] 本程序是自由软件；请参看源代码的版权声明。本软件没有任何担保； 包括没有适销性和某一专用目的下的适用性担保。 [code][root@hwclouds-ecs-100 ~]# \rm -rf /tmp/gcc [root@hwclouds-ecs-100 ~]# mkdir -p /tmp/cmake && cd /tmp/cmake [root@hwclouds-ecs-100 /tmp/cmake]# curl -Lk http://www.cmake.org/files/v3.8/cmake-3.8.1.tar.gz|tar xz -C /tmp/cmake --strip-components=1 [root@hwclouds-ecs-100 ~]# rm -rf /tmp/ 2017-05-17.hwclouds-ecs-100.dwhd.org.root.history-timestamp tcp-status.txt bison/ .Test-unix/ .font-unix/ .X11-unix/ httpNUB.txt .XIM-unix/ .ICE-unix/ [root@hwclouds-ecs-100 ~]# \rm -rf /tmp/bison/ [root@hwclouds-ecs-100 ~]# df -hP 文件系统 容量 已用 可用 已用% 挂载点 devtmpfs 482M 0 482M 0% /dev tmpfs 496M 0 496M 0% /dev/shm tmpfs 496M 6.6M 489M 2% /run tmpfs 496M 0 496M 0% /sys/fs/cgroup /dev/mapper/DTVG-root 10G 3.0G 7.1G 30% / /dev/xvda1 1014M 140M 875M 14% /boot tmpfs 100M 0 100M 0% /run/user/0 [root@hwclouds-ecs-100 ~]# [root@hwclouds-ecs-100 ~]# mkdir -p /tmp/cmake && cd /tmp/cmake [root@hwclouds-ecs-100 /tmp/cmake]# curl -Lk http://www.cmake.org/files/v3.8/cmake-3.8.1.tar.gz|tar xz -C /tmp/cmake --strip-components=1 [root@hwclouds-ecs-100 /tmp/cmake]# ./bootstrap && make -j$(getconf _NPROCESSORS_ONLN) && make install [root@hwclouds-ecs-100 /tmp/cmake]# cd && rm -rf /tmp/cmake [root@hwclouds-ecs-100 /usr/lib64]# cd [root@hwclouds-ecs-100 ~]# cmake --version cmake version 3.8.1 CMake suite maintained and supported by Kitware (kitware.com/cmake).[/code]