centos c语言(centos镜像)

老铁们，大家好，相信还有很多朋友对于centos c语言和centos镜像的相关问题不太懂，没关系，今天就由我来为大家分享分享centos c语言以及centos镜像的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！

CentOS如何查看当前系统下的gcc版本命令

1. gcc-v（Display the programs invoked by the compiler）

[root@localhost/]# gcc-v

Reading specs from/usr/i386-glibc-2.1-linux/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/specs

gcc version egcs-2.91.66 19990314/Linux(egcs-1.1.2 release)

2. rpm-qa|grep gcc

rpm-qi gcc

[root@localhost/]# rpm-qa|grep gcc

gcc-3.2.2-5

gcc-c++-3.2.2-5

libgcc-3.2.2-5

compat-gcc-7.3-2.96.118

gcc-g77-3.2.2-5

gcc-java-3.2.2-5

gcc-gnat-3.2.2-5

compat-gcc-c++-7.3-2.96.118

3. gcc-dumpversion（Display the version of the compiler）

[root@localhost/]# gcc-dumpversion

egcs-2.91.66

*******************************************************************************************

Linux系统下的Gcc（GNU C Compiler）是GNU推出的功能强大、性能优越的多平台编译器，是GNU的代表作品之一。gcc是可以在多种硬体平台上编译出可执行程序的超级编译器，其执行效率与一般的编译器相比平均效率要高20%~30%。

Gcc编译器能将C、C++语言源程序、汇程式化序和目标程序编译、连接成可执行文件，如果没有给出可执行文件的名字，gcc将生成一个名为a.out的文件。在Linux系统中，可执行文件没有统一的后缀，系统从文件的属性来区分可执行文件和不可执行文件。而gcc则通过后缀来区别输入文件的类别，下面我们来介绍gcc所遵循的部分约定规则。

.c为后缀的文件，C语言源代码文件；

.a为后缀的文件，是由目标文件构成的档案库文件；

.C，.cc或.cxx为后缀的文件，是C++源代码文件；

.h为后缀的文件，是程序所包含的头文件；

.i为后缀的文件，是已经预处理过的C源代码文件；

.ii为后缀的文件，是已经预处理过的C++源代码文件；

.m为后缀的文件，是Objective-C源代码文件；

.o为后缀的文件，是编译后的目标文件；

.s为后缀的文件，是汇编语言源代码文件；

.S为后缀的文件，是经过预编译的汇编语言源代码文件。

Gcc的执行过程

虽然我们称Gcc是C语言的编译器，但使用gcc由C语言源代码文件生成可执行文件的过程不仅仅是编译的过程，而是要经历四个相互关联的步骤∶预处理(也称预编译，Preprocessing)、编译(Compilation)、汇编(Assembly)和连接(Linking)。

命令gcc首先调用cpp进行预处理，在预处理过程中，对源代码文件中的文件包含(include)、预编译语句(如宏定义define等)进行分析。接着调用cc1进行编译，这个阶段根据输入文件生成以.o为后缀的目标文件。汇编过程是针对汇编语言的步骤，调用as进行工作，一般来讲，.S为后缀的汇编语言源代码文件和汇编、.s为后缀的汇编语言文件经过预编译和汇编之后都生成以.o为后缀的目标文件。当所有的目标文件都生成之后，gcc就调用ld来完成最后的关键性工作，这个阶段就是连接。在连接阶段，所有的目标文件被安排在可执行程序中的恰当的位置，同时，该程序所调用到的库函数也从各自所在的档案库中连到合适的地方。

Gcc的基本用法和选项

在使用Gcc编译器的时候，我们必须给出一系列必要的调用参数和文件名称。Gcc编译器的调用参数大约有100多个，其中多数参数我们可能根本就用不到，这里只介绍其中最基本、最常用的参数。

Gcc最基本的用法是∶gcc [options] [filenames]

其中options就是编译器所需要的参数，filenames给出相关的文件名称。

-c，只编译，不连接成为可执行文件，编译器只是由输入的.c等源代码文件生成.o为后缀的目标文件，通常用于编译不包含主程序的子程序文件。

-o output_filename，确定输出文件的名称为output_filename，同时这个名称不能和源文件同名。如果不给出这个选项，gcc就给出预设的可执行文件a.out。

-g，产生符号调试工具(GNU的gdb)所必要的符号资讯，要想对源代码进行调试，我们就必须加入这个选项。

-O，对程序进行优化编译、连接，采用这个选项，整个源代码会在编译、连接过程中进行优化处理，这样产生的可执行文件的执行效率可以提高，但是，编译、连接的速度就相应地要慢一些。

-O2，比-O更好的优化编译、连接，当然整个编译、连接过程会更慢。

-Idirname，将dirname所指出的目录加入到程序头文件目录列表中，是在预编译过程中使用的参数。C程序中的头文件包含两种情况∶

A)#include

B)#include“myinc.h”

其中，A类使用尖括号(>)，B类使用双引号(“”)。对于A类，预处理程序cpp在系统预设包含文件目录(如/usr/include)中搜寻相应的文件，而对于B类，cpp在当前目录中搜寻头文件，这个选项的作用是告诉cpp，如果在当前目录中没有找到需要的文件，就到指定的dirname目录中去寻找。在程序设计中，如果我们需要的这种包含文件分别分布在不同的目录中，就需要逐个使用-I选项给出搜索路径。

-Ldirname，将dirname所指出的目录加入到程序函数档案库文件的目录列表中，是在连接过程中使用的参数。在预设状态下，连接程序ld在系统的预设路径中(如/usr/lib)寻找所需要的档案库文件，这个选项告诉连接程序，首先到-L指定的目录中去寻找，然后到系统预设路径中寻找，如果函数库存放在多个目录下，就需要依次使用这个选项，给出相应的存放目录。

-lname，在连接时，装载名字为“libname.a”的函数库，该函数库位于系统预设的目录或者由-L选项确定的目录下。例如，-lm表示连接名为“libm.a”的数学函数库。

上面我们简要介绍了gcc编译器最常用的功能和主要参数选项，更为详尽的资料可以参看Linux系统的联机帮助。

假定我们有一个程序名为test.c的C语言源代码文件，要生成一个可执行文件，最简单的办法就是∶

gcc test.c

这时，预编译、编译连接一次完成，生成一个系统预设的名为a.out的可执行文件，对于稍为复杂的情况，比如有多个源代码文件、需要连接档案库或者有其他比较特别的要求，就要给定适当的调用选项参数。再看一个简单的例子。

整个源代码程序由两个文件testmain.c和testsub.c组成，程序中使用了系统提供的数学库，同时希望给出的可执行文件为test，这时的编译命令可以是∶

gcc testmain.c testsub.c□lm□o test

其中，-lm表示连接系统的数学库libm.a。

Gcc的错误类型及对策

Gcc编译器如果发现源程序中有错误，就无法继续进行，也无法生成最终的可执行文件。为了便于修改，gcc给出错误资讯，我们必须对这些错误资讯逐个进行分析、处理，并修改相应的语言，才能保证源代码的正确编译连接。gcc给出的错误资讯一般可以分为四大类，下面我们分别讨论其产生的原因和对策。

第一类∶C语法错误

错误资讯∶文件source.c中第n行有语法错误(syntex errror)。这种类型的错误，一般都是C语言的语法错误，应该仔细检查源代码文件中第n行及该行之前的程序，有时也需要对该文件所包含的头文件进行检查。有些情况下，一个很简单的语法错误，gcc会给出一大堆错误，我们最主要的是要保持清醒的头脑，不要被其吓倒，必要的时候再参考一下C语言的基本教材。

第二类∶头文件错误

错误资讯∶找不到头文件head.h(Can not find include file head.h)。这类错误是源代码文件中的包含头文件有问题，可能的原因有头文件名错误、指定的头文件所在目录名错误等，也可能是错误地使用了双引号和尖括号。

第三类∶档案库错误

错误资讯∶连接程序找不到所需的函数库，例如∶

ld:-lm: No such file or directory

这类错误是与目标文件相连接的函数库有错误，可能的原因是函数库名错误、指定的函数库所在目录名称错误等，检查的方法是使用find命令在可能的目录中寻找相应的函数库名，确定档案库及目录的名称并修改程序中及编译选项中的名称。

第四类∶未定义符号

错误资讯∶有未定义的符号(Undefined symbol)。这类错误是在连接过程中出现的，可能有两种原因∶一是使用者自己定义的函数或者全局变量所在源代码文件，没有被编译、连接，或者干脆还没有定义，这需要使用者根据实际情况修改源程序，给出全局变量或者函数的定义体；二是未定义的符号是一个标准的库函数，在源程序中使用了该库函数，而连接过程中还没有给定相应的函数库的名称，或者是该档案库的目录名称有问题，这时需要使用档案库维护命令ar检查我们需要的库函数到底位于哪一个函数库中，确定之后，修改gcc连接选项中的-l和-L项。

排除编译、连接过程中的错误，应该说这只是程序设计中最简单、最基本的一个步骤，可以说只是开了个头。这个过程中的错误，只是我们在使用C语言描述一个算法中所产生的错误，是比较容易排除的。我们写一个程序，到编译、连接通过为止，应该说刚刚开始，程序在运行过程中所出现的问题，是算法设计有问题，说得更玄点是对问题的认识和理解不够，还需要更加深入地测试、调试和修改。一个程序，稍为复杂的程序，往往要经过多次的编译、连接和测试、修改。下面我们学习的程序维护、调试工具和版本维护就是在程序调试、测试过程中使用的，用来解决调测阶段所出现的问题

如何在centos6.5的kvm虚拟机中永久激活windows2008

一、激活原理

目前激活Windows7/Windows2008的各种方法充斥互联网，但公认比较完美的激活方式是将品牌机（例如DELL、LENOVO等）的SLIC信息表刷写进需要安装Windows系统的计算机BIOS中，将该计算机“仿真”为品牌机，然后安装微软的OEM版Windows7/Windows2008并自动激活。

相信喜欢搞破解的童鞋都应该知道其中的奥秘，微软和PC厂商为了减轻对于操作系统的激活负荷，对大多数品牌机实行了有别于联网激活的“SLIC激活机制”：当Windows操作系统启动时，就会自行读取本机BIOS中的SLIC信息表，以及操作系统的“OEM密钥”和“OEM证书”，如果三者完全吻合、验证一致，Windows7/Windows2008系统就会被识别为自动激活的OEM版本。

笔者研究发现，Windows2012（注意不是Windows2012_R2，下同）与以往激活Windows7/Windows2008的方式类似，依然可以采用刷写BIOS中SLIC信息表安装OEM版系统的方式实现永久激活，只不过激活Windows2012需要SLIC2.2版，经测试SLIC2.2能够向下兼容SLIC2.1/2.0。

众所周知，虚拟机软件也是有BIOS的，目前市场上常见的虚拟机软件，如VMware、Xen、Kvm等均通过软件仿真的方式“模拟”硬件BIOS。既然可以采用刷写计算机硬件BIOS的方式实现永久激活，那么如果能够将SLIC2.2信息表通过软件再编译方式“灌入”虚拟机的BIOS中，然后再安装Windows2012的OEM版本，不就可以与刷写BIOS硬件实现自动激活“异曲同工”了吗？

二、核心问题

激活原理已经非常明确了，现在的关键问题是如何重新编译Linux虚拟机的问题了，这涉及Linux内核的重新编译，一些菜鸟可能望而生畏，尽管编译 Linux全部内核确实需要较高的技术水平，但重新编译Linux的BIOS难度并不高，初学者也可以轻松实现。本文以Linux的常见版本CentOs6.5为例，详细讲解重新编译KVM虚拟机BIOS的步骤。本文的方法同样适用Ubuntu等 Linux版本。

CentOs6.5虚拟机KVM的BIOS实际是一个二进制的可执行文件，默认安装路径为/usr/share/seabios/bios.bin。笔者研究发现，KVM虚拟机BIOS使用的是开源软件 seabios，该软件的源代码可以在互联网上找到，开源组织也制作了为seabios软件增加相应SLIC信息表的补丁包，下载seabios的源代码并打上该补丁包，然后重新编译并替换Linux默认的bios.bin文件，就可以将虚拟机“仿真”为品牌机，然后自动激活OEM版的Windows2012系统了，这种激活方式是永久激活，激活后的Windows2012可以打上微软的后续补丁且绝对不会被封杀。

三、详细步骤

1.获取SLIC2.2信息表。当前SLIC2.1的信息表网上很容易找到，SLIC2.2的信息表不多，比较容易找到的是DELL版的SLIC2.2信息表。当然也可以找一台预装了Windows2012的品牌机（市面上比较常见的是DELL的机器），然后使用SLIC_Toolkit3.2工具导出该机器的SLIC表。SLIC2.1/2.2表为二进制文件，长度均为374字节（这一点一定要注意）。

2.安装CentOs6.5_x64版操作系统。记得把gcc安装上，然后将上一步已经获取的SLIC2.2表拷贝在/ opt目录中（假定文件名称为DELL_SLIC2.2.BIN）。

3.在root用户下安装git,、iasl及所有依赖包。

#yum install git

#yum install iasl//这是必须安装的包

4.使用git获取sealic项目的源码。

# mkdir bios//目录可以自己随便建

#cd bios

#git clone git://github.com/ghuntley/seaslic//获取源代码

#ls-ls

Seaslic//用git软件获取源代码后会有多出一个目录

# cd seaslic

#ls

patch.sh README.markdown seabios.patch seabios.submodule

//该目录共包含三个文件和一个子目录，其中子目录seabios.submodule需要删除掉，用我们后面下载的内容重建。

#rm-rf seabios.submodule

5.从地址code.coreboot.org/p/seabios下载的SeaBios的源码并解压。注意源代码一定要下载1.7.3.2版本的，这一点也很关键，千万不能搞错了。

#tar xzvf seabios-1.7.3.2.tar.gz解压在/bios目录下。

6.重建seabios.submodule

#cd/bios

# cp–r seabios-1.7.3.2 seaslic/seabios.submodule

# cd seaslic

# ls

patch.sh README.markdown seabios.patch seabios.submodule

进入我们重建的seabios.submodule目录，可以发现有bios的源代码存在：

# cd seabios.submodule

# ls

COPYING COPYING.LESSER Makefile README README.CSM src TODO tools vgasrc

# cd src

可以发现seabios的源代码，我们需要重新编译这些源代码，生成新的bios.bin文件，用于替代CentOs6.5系统自带的bios.bin。

7.查看/bios/seaslic/patch.sh文件。这是一个批处理文件，只有2行有用。用Linux的命令方式执行，为防止输入错误，最好从patch.sh中复制粘贴后在root用户下执行：

①将SLIC2.2文件转换为C语言包含文件格式（acpi-slic.hex）的命令：

#xxd-i/opt/DELL_SLIC2.2.BIN| grep-v-E"len"| sed's/unsigned char.*/static char SLIC[]={/'> seabios.submodule/src/acpi-slic.hex

说明：这条命令执行后将会把SLIC2.2表（即/opt/DELL_SLIC2.2.BIN文件）转换为C语言包含文件格式（文件名../src/acpi-slic.hex）,并以数组形式存在。这一步非常非常关键，转换完成的acpi-slic.hex文件应为2333字节。如果本条命令执行不成功的话，编译出来的bios.bin文件不会包含SLIC2.2信息，也就无法实现激活了。

②为acpi.c文件打补丁的命令：

# cd/bios/seaslic/seabios.submodule

#patch-p1<../seabios.patch

说明：这条语句执行后将给../ src/acpi.c文件打上补丁，执行后系统将会提示：

Hunk#1 succeeded at 20 with fuzz 2(offset-194 lines).

Hunk#2 succeeded at 37 with fuzz 2(offset-194 lines).

Hunk#3 succeeded at 631 with fuzz 2(offset-205 lines).

注意：至此我们的准备工作已经全部完成了，下面将重新编译生成新的bios了。

8.重新编译生成bios.bin文件

# cd/bios/seaslic/seabios.submodule

#make//编译需要花几十秒钟吧，应提示无错误、无警告，否则可能需要仔细检查以上步骤。

查看..seabios.submodule/out/bios.bin

看到最后生成的结果了吧，会在..seabios.submodule/out/中多出一个bios.bin文件，这个文件就是我们重新编译生成的虚拟机的bios，将用来替换KVM的系统原有的bios.bin文件。

说明：这里编译生成bios.bin文件包含有DELL品牌机的SLIC2.2，可以激活DELL的Windows2012_OEM版。同理，我们只要找到其他品牌机的SLIC2.2信息表，重新编译后就可以安装激活其他品牌机的OEM版Windows7/2008/2012（SLIC2.1只能支持Vista/Win7/2008，不支持 Win2012；SLIC2.2则支持XP/Vista以及Win2008/2012并兼容SLIC2.1），与刷写计算机硬件BIOS实现自动激活的方式相比，采用这种方式激活Windows的风险为零，非常适合批量激活虚拟机的Windows2008/Windows2012。

9.替换CentOs6.5系统默认的bios.bin文件

# cp out/bios.bin/usr/share/seabios/bios.bin

#reboot//重新启动一下宿主机，然后再重新启动Windows虚拟机，在启动KVM虚拟机的时候，可以发现虚拟机的bios已经更新为最新版本了。

10.激活windows2012

至此KVM虚拟机的bios已经重新配置完成，在KVM中启动WINDOWS客户机，然后利用SLIC_Toolkit3.2工具检查SLIC，会发现你的SLIC信息已经获取成功，如果你安装的是OEM版本的 Win2008/2012的话，无需输入key和证书就能自动激活。你可以从网上百度如下OEM镜像（我已试验过可自动激活）：

(1)Lenovo的OEM版Windows2008_R2镜像：

Windows_Server-2008_R2_ENT_OEM.iso或者

Win_Server_08_R2_SP1_33in1.iso

(2)Dell的OEM版Windows2012镜像：

Ser2012_ST_DA_OEM.iso

(3)如果你手上暂时没有OEM版的话，也不要紧，可以用slmgr命令手工增加证书及OEM序列号也可以激活Windows2008/20012。直接用管理员身份进入命令行模式：

①slmgr-ilc DELL2.2.XRM-MS//这里找到的是DELL计算机的Windows2012版OEM证书。

②接下来就是写入注册号了：

slmgr-ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX

说明：下面是我从网上找到的 OEM版序列号（经测试可以激活）：

Windows Server 2012 Standard DELL OEM KEY

2G9DG-XKFR6-VG8D3-DN9T9-CDG98

Windows Server 2012 Datacenter DELL OEM KEY

2BVGY-TNRWK-6927W-866R9-66J3H

Windows Server 2008 R2 Standard DELL OEM KEY

D7TCH-6P8JP-KRG4P-VJKYY-P9GFF

Windows Server 2008 R2 Enterprise DELL OEM KEY

BKCJJ-J6G9Y-4P7YF-8D4J7-7TCWD

③执行slmgr–dlv//显示全部激活信息

④执行slmgr-xpr//显示Windows2008/2012已经永久激活。

centos7怎么编译安装gcc-c++

方法/步骤

1

yum install glibc-static libstdc++-static-y

安装c和c++的静态库（据说如果系统中缺少libc.a和libstdc++.a编译时会出错，但是我没有那么多闲情逸致去试，实践过的朋友可以回复一下，分享一下经验，让大家都长长见识）

2

下载解压gcc，我的gcc目录是gcc-4.8.0

3

进入gcc目录，执行：

./contrib/download_prerequisites

这个神奇的脚本文件会帮我们下载、配置、安装那三个依赖的库。可以节约我们大量的时间和精力。

4

你以为这三个库自动下载了、自动make install了就没事了吗？错！

很多人在编译gcc的时候出现各种奇奇怪怪的错误就是这步没有做好。

它们还不在.so文件的搜索路径里面，需要加进去，最后切记切记一定要执行一下ldconfig。

大致做法为：

1，找到你的共享库文件被install到哪个目录了（updatedb+locate命令）。

2，如果你的库不是直接放在/lib或/usr/lib下，需要修改/etc/ld.so.conf文件，加入你的共享库的路径

3，如果在2中添加了共享库路径，切记要执行一下ldconfig，更新响应cache文件让系统能找到你的共享库。

5

建立临时目录，这个目录用以存放编译时的大量临时文件，是文档要求中必须的。

我是在gcc-4.8.0下建立了一个名为gcc-build-4.8.0的目录，进入它。

mkdir gcc-build-4.8.0

cd gcc-build-4.8.0

配置gcc编译选项

6

强烈建议阅读INSTALL目录下的说明文档，尤其是configure.html，以确定你的编译选项。

比较基本的选项有--enable-languages，说明你要让你的gcc支持那些语言，--disable-multilib不生成编译为其他平台可执行代码的交叉编译器。--disable-checking生成的编译器在编译过程中不做额外检查，也可以使用--enable-checking=xxx来增加一些检查。

网上还说了什么--with-gmp、--with-mpfr、--with-mpc这三个选项，但是如果你3,4步做好了，就不要配了，反之你还是老实点吧别抱侥幸心理了。

调用gcc-4.8.0目录下的configure文件：

例如：

../configure--enable-checking=release--enable-languages=c,c++--disable-multilib

7

执行

../make#不解释

执行编译命令（#在8核的虚拟机上进行编译,每个核分配2个编译任务）

make-j16

make install编译过程CPU核基本100%占用，整个编译用时11分50秒。

检查gcc版本

#你就等吧少年，建议晚上睡觉前做

当然上面三步一定要在前一步顺利结束的情况下进行，如果哪一步出错了，结果都显示error了，就不要再做后面的了。在shell的输出里搜索"error"看具体的出错点是什么，baidu、google一下为什么。

如果你求稳的话，可以在make install之前先make check一下。