GCC

一、简介:

gcc 最初是 "GNU C Compiler" 的简称,只是当作一个 C 语言的编译器,现在已经变成了 "GNU Compiler Collection",可以编译多种语言。

 

 

二、编译的四个阶段:

在使用 gcc 编译程序时,编译过程可以被细分为 4 个阶段:

 预处理(Pre-Processing)

 编译(Compiling)

 汇编(Assembling)

 链接(Linking)

下面以一份简单的 C 代码来说明:

#include <stdio.h>
int main()
{
    printf("Hello,World!\n");
}

在使用GCC编译时, 可以直接使用 gcc test.c -o test 命令一次性完成编译(注:如果使用 gcc 命令(未做g++的软链接)来编译 C++ 库,需要链接 -lstdc++ 库。),也可以分成 4 个步骤分步编译:

gcc -E test.c -o test.i   //需要使用 -o 将预处理后的结果输出到 test.i (仍然是 C 代码),否则只将预处理后结果输出到屏幕。
gcc -S test.i         //将预处理后的代码进行反汇编,生成汇编代码
gcc -c test.s         //将汇编代码编译成目标文件,即二进制代码。-c 可以直接把 C/C++ 代码编译成机器代码。
gcc test.o -o test      //将中间文件链接成可执行文件

本人使用的 gcc 安装在 CentOS 6.4 64bit 上的 /usr/local/gcc-4.8.1 目录,故以此为例说明:

1、预处理阶段:调用 cpp 命令

cpp test.c -o test.i

2、编译阶段:调用 cc1 命令(如果是 C++ 代码则使用 cc1plus 命令)

/usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/cc1 test.i

3、汇编阶段:调用 as 命令

as test.s -o test.o

4、连接阶段:调用 ld 命令(如果是 C++ 代码还需要链接 -lstdc++)

ld -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o test test.o /usr/lib64/crt1.o /usr/lib64/crti.o -lc /usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtbegin.o /usr/local/gcc-4.8.1/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/crtend.o /usr/lib64/crtn.o

注:可以通过 -v 参数打印出编译器内部编译各过程的命令行信息和编译器的版本,如 gcc -v test.c 2>&1 | grep cc1 ,另外关于 ld 链接 C/C++ ,可参考:

http://stackoverflow.com/questions/14163208/how-to-link-c-object-files-with-ld

 

 

三、头文件的处理

GCC 的 -I 参数可以用来指定头文件目录,当前目录和缺省目录(/usr/include && /usr/local/include)不用指定。

另外,-include 用来包含某个头文件,但一般情况下因为已经在源码里用 #include 指令实现了,所以这个很少用。

环境变量 C_INCLUDE_PATH 和 CPLUS_INCLUDE_PATH ,分别用来指定 C 与 C++ 的默认的头文件目录。那么,该方法与使用 -I 来包含头文件有什么区别呢?区别是,在使用 GCC -MM 生成依赖关系时,前者会忽略生成指定路径的头文件的依赖关系,即编译时不依赖于环境变量中指定的头文件,这在我们使用稳定的第三方库头文件时,非常有利于编译检查的时间优化,如 BOOST 库等。-M 选项生成文件关联的信息,包含目标文件所依赖的所有源;而 -MM 选项会忽略由 #include <...> 造成的依赖关系。-MD 选项与 -M 相同,只是将依赖关系写到 .d 文件中去,同样的 -MMD 也是如此。

 

在代码中使用 #include <stdio.h> 与使用 #include "stdio.h" 一般都可以使代码正常编译,但对于预处理程序 cpp 的工作效率是有影响的,前者会优先搜索系统默认头文件目录,而后者会优先搜索当前目录,如果没有搜到就到 -I 指定的目录去搜索。

 

 

四、链接库的处理

下面先来看看静态库和动态库是如何生成的:

◆ 静态链接库其实就可以看成是 *.o 文件的简单打包:

ar -cr libtest.a test.o      或: ar -cr libtest.a test.cpp

-r 选项是必须的,表示插入到备份文件,并且有则替换 -c 表示创建备份文件

(一段小历史:最早的 ar 命令只是用来打包文件的,就类似 tar 一样,并不处理 .o 文件里的符号表,所以出现一个名为 ranlib 的工具来做这件事,后来被厂商集成到 ar 命令中,相当于 ar -s,现在只要使用 ar 命令,已经默认使用了 ranlib 的功能。)

◆ 动态链接库优于静态链接库,无论是在内存使用和磁盘使用上(多进程时),既可以使用源码文件直接生成,也可以使用 *.o 文件生成(*.o 文件的生成必须使用 -fPIC 参数,而从*.o 文件生成动态链接库则不用再重复此参数):

gcc -c -fPIC test.cpp && gcc test.o -o libtest.so -shared
或: gcc test.cpp -o libtest.so -shared -fPIC

-shared 该选项指定生成动态连接库(让连接器生成T类型的导出符号表,有时候也生成弱连接W类型的导出符号),不用该标志外部程序无法连接。相当于一个可执行文件。

-fPIC 表示编译为位置独立的代码,不用此选项的话编译后的代码是位置相关的,所以动态载入时是通过代码拷贝的方式来满足不同进程的需要,而不能达到真正代码段共享的目的。 

(小知识:可以通过 ldd 命令来查看可执行文件需要哪些动态链接库) 

 

再来看看 gcc 如何使用静态库和动态库:

编译时可以直接带上完整路径的链接库进行编译,如 g++ main.cpp lib/libmyfun.so -o main ,但更多的是使用下面的方法。

gcc 使用 -l 参数来指定链接库,如链接 libtest.a 或 libtest.so,使用 -ltest。使用 -l 链接时去除 lib 前缀和后缀即可。

编译时,默认的链接库目录为 /usr/lib && /usr/local/lib ,如果是64位系统,还有 /usr/lib64;否则就需要通过 -L 参数来指定自定义链接库目录。(注:有的LINUX发行版好像不支持 /usr/local/lib 和 /usr/local/lib64,所以最好是使用 /usr/lib)

静态库链接后,是将代码直接嵌入到可执行文件中,所以运行时,不需要再指定静态库;而动态库则不然。如果动态库位于系统默认的库目录,则可直接运行,如果是自定义目录,有以下三种方法可以配置:

1、直接执行:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/project/lib

可临时生效,(重启后失效)

2、 ~/.bashrc 或者 ~/.bash_profile 里添加上面的命令:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/project/lib

重启终端生效。

3、编辑 /etc/ld.so.conf 文件(或者在 /etc/ld.so.conf.d 目录下新建一个 project.conf 文件),添加自定义动态库路径,然后使用 ldconfig 命令更新,使其生效。

当静态库和动态库同时存在时,程序会优先使用动态库,如果需要强制只使用静态库,可使用 -static 选项,此时不会链接任何动态库,生成的目标文件会比较大。

此外,还有另外一种方式,在链接时加上如 -L../lib -Wl,-rpath=../lib 选项,则可以指定编译好的程序在运行时动态库的优先搜索目录,这种方法会将动态库路径写入到elf文件中去,即使找不到,也可以再去环境变量指定路径去寻找。该方式便于部署,可把动态库跟配置文件一样放在单独文件夹里,与可执行文件一起打包发给运维即可运行。总结一下:-rpath制定的搜索路径,优先于LD_LIBRARY_PATH 和 /etc/ld.so.conf ,另外它是被写入到可执行文件中的。可以使用 ldd 命令查看可执行文件中使用的动态链接库和相应路径。

(小知识:我们可以给链接库带一个版本号,如 libmyfun.so.6,然后用 ln -s libmyfun.so.6 libmyfun.so,项目中链接 libmyfun.so 即可。gcc库文件的 libstdc++.so.6 就是如此)

 

运行时,Linux动态链接库的搜索路径按优先级排序为:

1、编译目标代码时 ”-Wl,-rpath,” 指定的动态库搜索路径(当指定多个动态库搜索路径时,路径之间用冒号”:”分隔。);

2、环境变量 LD_LIBRARY_PATH 指定的动态库搜索路径;

3、配置文件 /etc/ld.so.conf 中指定的动态库搜索路径;

4、默认的动态库搜索路径 /lib,如果是64位系统还包括 /lib64;

5、默认的动态库搜索路径 /usr/lib,如果是64位系统还包括 /usr/lib64;

注意: /usr/local/lib 和 /usr/local/lib64 居然不在标准路径之列。

 

 

五、静态检查

-pedantic     //检查代码是否符合 ANSI/ISO 标准:
-Wall       //输出警告信息
-Wextra      //输出更多的警告信息
-Weffc++      //检查是否符合 《Effective C++》这本书中提到的标准
-w        //关闭所有警告

 

 

六、调试与优化

-g            //在编译时生成原生格式的调试符号信息,可以使用 gdb 或 ddx 等调试器调试。-g 分为三个级别,默认为 -g2,其中 -g3 除包含 -g2 中的所有调试信息外,还包含源代码中定义的宏。
-ggdb          //在编译时生成 gdb 专用格式的调试符号信息,信息更为丰富,但只能使用 gdb 调试,而不能使用其它调试器。级别设定与 -g 基本相同。
-gdwarf        //如果升级 GCC 之后,发现 GDB 不能用了,那么在编译的时候加上 -gdwarf 选项试一下,如果还不行,再使用 -gdwarf-2 试试。
-p           //将剖析(Profiling)信息加入到最终生成的二进制代码中,生成可以被通用剖析工具(Prof)能够识别的统计信息,它对于找出程序瓶颈很有帮助。生成后的可执行文件要运行一次,才能生成剖析文件,默认文件名是 gmon.out。
-pg            //生成只有 GNU 剖析工具(Gprof)才能识别的统计信息。
-save-temps     //保存编译过程中生成的一系列中间文件。
-On          //n 可以为 0~3,默认为 1,数字越大优化越高,一般使用 -O2 可以在优化长度、编译时间和代码大小之间取得较好平衡,开发调试建议使用 -O0
-Os          //相当于 -O2.5,使用了所有 -O2 的优化选项,但却没有使用增加大小。也就是说,相对于 -O2,能减少一点可执行文件的大小。
-s          //从执行文件中删除符号表与重定向信息,以减少执行文件的大小。跟直接编译之后,使用 strip 命令减小文件大小效果一致。

 

 

七、编译器扩展

#include <iostream>
#include <string>

class T
{
    public:
    void fun(std::string s,double d)
    {
        std::cout<<__FUNCTION__<<std::endl;  //输出函数名
        std::cout<<__PRETTY_FUNCTION__<<std::endl;  //输出函数完整原型
    }
};

int main()
{
    T().fun("Hello",3.1);
}

输出结果如下:

 

 

八、GCC 版本升级

通过源码安装新版本的GCC,要保证已经安装了GCC编译器:

1、下载源码包

下载高版本GCC源码包

ftp://ftp.gnu.org/gnu/gmp 下载最新版

http://ftp.gnu.org/gnu/mpfr/ 下载 mpfr 最新版

http://www.multiprecision.org/mpc 下载 mpc 最新版


2、依次安装 gmp 、mpfr、mpc

./configure --prefix=/usr/local/gmp-5.1.1&&  make -j4  && make install
./configure --prefix=/usr/local/mpfr-3.1.2 --with-gmp=/usr/local/gmp-5.1.1&& make -j4  && make install
./configure --prefix=/usr/local/mpc-1.0 --with-gmp=/usr/local/gmp-5.1.1 --with-mpfr=/usr/local/mpfr-3.1.2&& make -j4 && make install


3、安装GCC

 //export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/mpc-1.0/lib:/usr/local/gmp-5.1.1/lib:/usr/local/mpfr-3.1.2/lib
./configure --prefix=/usr/local/gcc-4.8 --enable-threads=posix --disable-checking --disable-multilib --enable-languages=c,c++ --with-gmp=/usr/local/gmp-5.1.1 --with-mpfr=/usr/local/mpfr-3.1.2 --with-mpc=/usr/local/mpc-1.0   --with-gmp-lib=/usr/local/gmp-5.1.1/lib --with-mpfr-lib=/usr/local/mpfr-3.1.2/lib --with-mpc-lib=/usr/local/mpc-1.0/lib
make -j4 && make install

 

4、做软链接

ln -s /usr/local/gcc-4.8/bin/gcc  /usr/bin/gcc
ln -s /usr/local/gcc-4.8/bin/g++  /usr/bin/g++
cp /usr/local/mpc-1.0/lib/libmpc.so /usr/local/gmp-5.1.1/lib/libgmp.so /usr/local/mpfr-3.1.2/lib/libmpfr.so /lib64/

 

这时候用gcc来编译C++程序会报缺少一些C++标准库,这时候可以使用 gcc -lstdc++ 或直接使用 g++ 命令。

 

5、解决 GDB 的问题

升级 gcc 之后,编译代码加上 -g 选项,在使用 gdb 调试时,可能会出现  Missing separate debuginfos, use: debuginfo-install libgcc-4.4.7-3.el6.x86_64 这样的错误,是因为只加 -g 选项,此时已经无法生成符号表了。解决方案有两种:

◆ 编译时加上 -gdwarf 选项试一下,如果还不行,再使用 -gdwarf-2 试试。

◆ 升级 gdb 版本,可升级至 7.6 ,正常的 ./configure && make && make install 之后,就可以正常使用了。如果 make 过程中出现 configure: error: no termcap library found 的错误,可以 yum install ncurses-devel 来解决。

 

预编译头:

gcc -x c++-header -c stdc++.h -o stdc++.h.gch -std=c++0x

 

6、当执行一个可执行文件时,如果报类似 `GLIBCXX_3.4.15' not found 的错误,是因为编译这个可执行文件的GCC版本和当前环境中的GCC版本不同,可以选择升级GCC版本,如下网页:

http://blog.csdn.net/davidwang9527/article/details/19197511、

 

7、如果只是将GCC4.8.2编译的可执行文件配置到一台LINUX机器上运行,并不需要安装GCC4.8.2,只需要将原机器上的 /usr/local/gcc-4.8.2/lib64/libstdc++.so.6 文件复制到新机器的 /usr/lib64/libstdc++.so.6 即可(注意备份原文件)

posted @ 2013-10-09 13:58  轻典  阅读(14584)  评论(0编辑  收藏  举报