当你在linux下写C/C++代码的时候，是不是会遇到许多编译链接的问题？ 时不时报个glibc,gcc，g++等相关的错误？ 很多时候都无从下手，而且比较混乱。 这也是编译链接过程中经常出现的问题。

这篇文章不是去介绍如何编译链接，而是理清编译链接过程中碰到的一些概念和出现的问题。尤其是，libc,glib,glibc,eglibc,libc++,libstdc++,gcc,g++。

从libc说起。
libc是Linux下原来的标准C库，也就是当初写hello world时包含的头文件#include < stdio.h> 定义的地方。

后来逐渐被glibc取代，也就是传说中的GNU C Library,在此之前除了有libc，还有klibc,uclibc。现在只要知道用的最多的是glibc就行了，主流的一些linux操作系统如 Debian, Ubuntu，Redhat等用的都是glibc（或者其变种，下面会说到).

那glibc都做了些什么呢？ glibc是Linux系统中最底层的API，几乎其它任何的运行库都要依赖glibc。 glibc最主要的功能就是对系统调用的封装，你想想看，你怎么能在C代码中直接用fopen函数就能打开文件？ 打开文件最终还是要触发系统中的sys_open系统调用，而这中间的处理过程都是glibc来完成的。这篇文章详细介绍了glibc是如何与上层应用程序和系统调用交互的。除了封装系统调用，glibc自身也提供了一些上层应用函数必要的功能,如string,malloc,stdlib,linuxthreads,locale,signal等等。

好了，那eglibc又是什么？ 这里的e是Embedded的意思，也就是前面说到的变种glibc。eglibc的主要特性是为了更好的支持嵌入式架构，可以支持不同的shell(包括嵌入式)，但它是二进制兼容glibc的，就是说如果你的代码之前依赖eglibc库，那么换成glibc后也不需要重新编译。ubuntu系统用的就是eglibc（而不是glibc）,不信，你执行 ldd –version 或者 /lib/i386-linux-gnu/libc.so.6
(64位系统运行/lib/x86_64-linux-gnu）看看，便会显示你系统中eglibc/glibc的版本信息。 这里提到了libc.so.6,这个文件就是eglibc/glibc编译后的生成库文件。

还有一个glib看起来也很相似，那它又是什么呢？glib也是个c程序库，不过比较轻量级，glib将C语言中的数据类型统一封装成自己的数据类型，提供了C语言常用的数据结构的定义以及处理函数，有趣的宏以及可移植的封装等(注：glib是可移植的，说明你可以在linux下，也可以在windows下使用它）。那它跟glibc有什么关系吗？其实并没有，除非你的程序代码会用到glib库中的数据结构或者函数，glib库在ubuntu系统中并不会默认安装(可以通过apt-get install libglib2.0-dev手动安装)，著名的GTK+和Gnome底层用的都是glib库。想更详细了解glib？ 可以参考这里

看到这里，你应该知道这些库有多重要了吧？ 你写的C代码在编译的过程中有可能出现明明是这些库里面定义的变,却量还会出现’Undefined’, ‘Unreference’等错误，这时候你可能会怀疑是不是这些库出问题了？ 是不是该动手换个gilbc/eglibc了？ 这里强调一点，在你准备更换/升级这些库之前，你应该好好思考一下，你真的要更换/升级吗？你要知道你自己在做什么！你要时刻知道glibc/eglibc的影响有多大，不管你之前部署的什么程序，linux系统的ls,cd,mv,ps等等全都得依赖它，很多人在更换/升级都有过惨痛的教训，甚至让整个系统奔溃无法启动。所以，强烈不建议更换/升级这些库！

当然如果你写的是C++代码，还有两个库也要非常重视了，libc++/libstdc++,这两个库有关系吗？有。两个都是C++标准库。libc++是针对clang编译器特别重写的C++标准库，那libstdc++自然就是gcc的事儿了。libstdc++与gcc的关系就像clang与libc++. 其中的区别这里不作详细介绍了。

再说说libstdc++，glibc的关系。 libstdc++与gcc是捆绑在一起的，也就是说安装gcc的时候会把libstdc++装上。 那为什么glibc和gcc没有捆绑在一起呢？
相比glibc，libstdc++虽然提供了c++程序的标准库，但它并不与内核打交道。对于系统级别的事件，libstdc++首先是会与glibc交互，才能和内核通信。相比glibc来说，libstdc++就显得没那么基础了。

说完了这些库，这些库最终都是拿来干嘛的？当然是要将它们与你的程序链接在一起！ 这时候就不得不说说gcc了(当然还有前文提到的clang以及llvm等编译器，本文就不细说它们的区别了)。

你写的C代码.c文件通过gcc首先转化为汇编.S文件，之后汇编器as将.S文件转化为机器代码.o文件，生成的.o文件再与其它.o文件，或者之前提到的libc.so.6库文件通过ld链接器链接在一块生成可执行文件。当然，在你编译代码使用gcc的时候，gcc命令已经帮你把这些细节全部做好了。

那g++是做什么的? 慢慢说来，不要以为gcc只能编译C代码，g++只能编译c++代码。 后缀为.c的，gcc把它当作是C程序，而g++当作是c++程序；后缀为.cpp的，两者都会认为是c++程序，注意，虽然c++是c的超集，但是两者对语法的要求是有区别的。在编译阶段，g++会调用gcc,对于c++代码，两者是等价的，但是因为gcc命令不能自动和C++程序使用的库联接，需要这样，gcc -lstdc++, 所以如果你的Makefile文件并没有手动加上libstdc++库，一般就会提示错误，要求你安装g++编译器了。

好了，就说到这，理清这些库与编译器之间的关系，相信会对你解决编译链接过程中遇到的错误起到一点帮助。

如果你的编译器不支持一些新的C/C++特性，想升级gcc/g++, 这里也给出一个基于ubuntu系统的参考方法。

添加ppa

sudo add-apt-repository ppa:ubuntu-toolchain-r/test sudo apt-get update 

添加ppa，是因为你所用的ubuntu版本的更新源中可能并没有你想要的gcc/g++版本。

安装新版gcc/g++

sudo apt-get install gcc-4.8 sudo apt-get install g++-4.8 

可以到/usr/bin/gcc查看新安装的gcc,g++

配置系统gcc/g++

使用update-alternatives,统一更新gcc/g++

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.6 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 80 --slave /usr/bin/g++ g++ /usr/bin/g++-4.8 sudo update-alternatives --config gcc 

数字优先级(如60，80)高的会被系统选择为默认的编译器,也可以执行第三条命令就是来手动配置系统的gcc,此处按照提示,选择4.8版本的即可。

转载：http://www.chongh.wiki/blog/2016/05/25/lib-compile-link/

回归正题，前段时间项目开发中，实现了一个动态库，封装了一些方法。然后基于这个动态库，实现了一个应用程序。应用程序中含有全局变量A，动态库中也含有全局变量A，当我调用动态库中函数后，发现应用程序的A发生了变化！！！O，My God！对于我这种还没在Linux下做过开发的人来说，一头雾水。。。。。。 于是我尝试着，将A中的变量名称改为B，这样问题也就没有了~~~

原因

应用程序进行链接的时候，动态库中全局变量定义，将会被应用程序中同名的全局变量所覆盖。这样也就造成了，在动态库中修改A变量时，应用程序中的A也发生了变化。

解决方法

在创建动态链接库时，gcc/g++选项中添加编译选项

-Wl,-Bsymbolic.

unix平台下，动态连接库的使用有两种方式，link方式和dlopen方式。需要设置LD_LIBRARY_PATH作为查找路径（低版本AIX使用LIBPATH）。link方式是程序启动时加载所有编译时连接的动态库，直到程序结束也不会关闭。dlopen方式是在运行中按照参数指定的方式加载动态库，并可以使用dlclose函数关闭，直到下次再使用dlopen重新加载。因此，link方式无法做到不重启应用程序而更新动态库版本，dlopen方式可以。

各平台动态连接库的编译参数如下。文件wel.c，编译成libwel.so（HPUX为libwel.sl）。

 linux:
  编译libwel.so:
   gcc -fPIC -shared -o libwel.so wel.c -lc
    -fPIC  用相对地址定位
    -shared  生成动态连接库

 sco unix open server:
  编译libwel.so:
   cc -K PIC -G -o libwel.so wel.c -lc
    -K PIC  用相对地址定位
    -G  生成动态连接库，包含了-b elf选项

 AIX:
  编译libwel.so:
   xlc -G -bnoentry -o libwel.so wel.c -lc
    -G  指定生成动态连接库
    -bnoentry 动态库无需模块入口（低版本AIX需要此参数）

 HP UX:
  编译libwel.so:
   cc +z -c wel.c
   ld -b -o libwel.sl wel.o -lc
    +z  用相对地址定位
    -b  生成动态连接库

 SUN OS: 很类似SCO，man帮助不全面
  编译libwel.so:
   cc -G -o libwel.so wel.c -lc
    -G  生成动态连接库

link方式使用动态连接库的编译参数如下。文件welcome.c，编译成welcome可执行程序。

 linux:
   gcc -rdynamic -o welcome welcome.c -L. -lwel
    -rdynamic  导出所有符号供动态使用

 sco unix open server:
   cc -b elf -o welcome welcome.c -L. -lwel
    -b elf  必须使用ELF的可执行文件格式

 AIX:
   xlc -bdynamic -brtl -o welcome welcome.c -L. -lwel
    -bdynamic 使用动态连接方式，系统默认为此方式
    -brtl  -l参数使用.so为库

 HP UX:
   cc -dynamic -o welcome welcome.c -L. -lwel
    -dynamic 使用动态连接方式，系统默认为此方式

 SUN OS:
  编译libwel.so:
   cc -B dynamic -o welcome welcome.c -L. -lwel
    -B dynamic 使用动态连接方式

dlopen方式，其实就是把打开动态库和查找符号的动作放在程序中执行。因此编译可执行文件与普通的相同，只要连接libdl.so库即可。文件welcome.c，编译成welcome可执行程序。

 linux:
   gcc -rdynamic -o welcome welcome.c -ldl
    -rdynamic 导出所有符号供动态使用
    -ldl  用系统libdl.so库dlopen(),dlsym(),dlerror(),dlclose()

 sco unix open server:
   cc -b elf -o welcome welcome.c -lc
    -b elf  以elf格式，动态连接库必须

 AIX:
   xlc -bexpall -o welcome welcome.c -ldl -lc
    -bexpall 使主程序的符号可以被动态库使用

 HP UX:
   cc -o welcome welcome.c -ldl -lc

 SUN OS:
   cc -o welcome welcome.c -ldl -lc

------------------------------------------------------------------------------
参照的man手册：
 cc, ld, ldd, dlopen, dlclose, dlerror, dlsym, CC

另：AIX运行动态库时会加载系统内存统一管理，导致即使程序已退出，编译时仍然认为还在使用而无法覆盖。有两个办法，一是root用户执行slibclean，清理系统加载而无人使用的动态库，另一种是编译的库chmod go-rwx，使得组和其他人无权限，这种库系统会认为用户特有而不加载。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/283313/viewspace-2139257/，如需转载，请注明出处，否则将追究法律责任。

if [ $STATUS == "OK" ]; then     

echo "OK"

fi

    在运行时出现了“ [: =: unary operator expected” 的错误，就一直找不到原因，尝试了删除等号两侧的空格和括号里的空格都不管用。最后baidu了一下，才找到原因，在条件表达式外再添加一层“[]”，就不会出错了，如下：

if [[ $STATUS = "OK" ]]; then    

echo "OK"

fi 

    究其原因，是因为如果变量STATUS值为空，那么条件表达式就成了 [ = "OK"] ，显然 [ 和 "OK" 不相等并且缺少了 [ 符号，所以报了这样的错误。当然不总是出错，如果变量STATUS值不为空，程序就正常了，所以这样的错误还是很隐蔽的。

    或者，用下面的方法也能避免这种错误：

if [ "$STATUS"x == "OK"x ]; then     

echo

"OK"

fi。

当然，x也可以是其他字符。顺便提一点，shell中有没有双引号在很多情况下是一致的。

转自：http://hi.baidu.com/vishare/blog/item/bd8ab9ee289753252cf53417.html

在C++中，有时候需要在不同文件中使用同一个变量。对于这类变量如果处理不当，很容易出现“multiple definition of... first defined here”的错误。

例如，定义了如下3个文件：global.h, a.cpp, b.cpp

//global.h: #ifndef _GLOBAL_H_ #define _GLOBAL_H_  const int a=1; int b;  #endif

//a.cpp #include <iostream> #include <stdlib.h> #include "global.h"  using namespace std;  void test1() {      cout<<"test1"<<endl; }

//b.cpp #include <iostream> #include <stdlib.h> #include "global.h"  using namespace std;  void test2() {     cout<<"test2"<<endl; }  void main() {   cout<<"hello world"<<endl; }

执行编译命令：

g++ -o main a.cpp b.cpp

提示错误为：

[chris@zz jojo]g++ -o main a.cpp b.cpp
/tmp/ccc7OcsO.o:(.bss+0x0): multiple definition of `b'
/tmp/ccs7q2VA.o:(.bss+0x0)：第一次在此定义

出错原因：a.cpp和b.cpp先分别被编译为.o格式的目标文件，两个目标文件再被链接器链接起来，这当中a.cpp和b.cpp分别进行了一次include，相当于global.h中的代码重复出现了一次。因为a是const类型，所以重新定义也没事；但是b只是普通变量，重复定义显然不行。

显然，一个解决办法是把b定义为const int类型。或者，定义成static int类型也行。

还有一种解决方案，就是把global.h变为global.c文件，a.cpp和b.cpp中不再include它，但是编译的时候把global.c也编译进去，就可以了：

g++ -o main global.c  a.cpp b.cpp

再举一个class相关的例子。比如有Body和Mouth两个类，Body的greet方法会调用Mouth的say方法，而main函数中会调用全局变量body的greet方法。为了只是用一个body和一个mouth对象，可以这么写：

//body.h #ifndef BODY_H #define BODY_H  #include <mouth.h>  class Body { public:     Body();     ~Body();     void greet(); };  extern Body body;   #endif 

//body.cpp #include <body.h>  Body::Body(){}  Body::~Body() {}  void Body::greet() {     mouth.say(); } 

//mouth.h #ifndef MOUTH_H #define MOUTH_H  class Mouth { public:     Mouth();     ~Mouth();     void say(); };  extern Mouth mouth;   #endif 

//mouth.cpp #include <mouth.h> #include <iostream>  using namespace std;  Mouth::Mouth() {}  Mouth::~Mouth() {}  void Mouth::say() {     cout << "Have a Nice day!" << endl; } 

//class.cpp #include <body.h> #include <mouth.h>   Body body; Mouth mouth; 

//main.cpp #include <iostream> #include <body.h> using namespace std;  int main() {     body.greet(); } 

上面代码中的include，虽然都是用的尖括号，但因为编译时可以通过指定include路径，不会出问题～
编译命令：

g++ -I ./ mouth.cpp body.cpp class.cpp main.cpp -o main

能够正常运行。

错误：

host C++: libutils <= frameworks/base/libs/utils/AssetDir.cpp

host C++: libutils <= frameworks/base/libs/utils/Asset.cpp
g++: 错误： –fpermissive：没有那个文件或目录
make: *** [out/host/linux-x86/obj/STATIC_LIBRARIES/libutils_intermediates/Asset.o] 错误 1
make: *** 正在等待未完成的任务....
g++: 错误： –fpermissive：没有那个文件或目录
make: *** [out/host/linux-x86/obj/STATIC_LIBRARIES/libutils_intermediates/AssetDir.o] 错误 1

true

是传递给g++的标志被误判成文件名了。用"make showcommands"编译，贴出完整的输出。

host C++: libutils <= frameworks/base/libs/utils/AssetDir.cpp
g++  -I external/zlib   -I frameworks/base/libs/utils   -I out/host/linux-x86/obj/STATIC_LIBRARIES/libutils_intermediates   -I dalvik/libnativehelper/include/nativehelper   -I system/core/include   -I hardware/libhardware/include   -I hardware/libhardware_legacy/include  
-I hardware/ril/include   -I dalvik/libnativehelper/include   -I frameworks/base/include   -I frameworks/base/opengl/include   -I frameworks/base/native/include   -I external/skia/include   -I tools/include   -I out/host/linux-x86/obj/include  -c  -fno-exceptions
-Wno-multichar -m32 -fPIC -include system/core/include/arch/linux-x86/AndroidConfig.h -D_FORTIFY_SOURCE=0 -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -O2 -g -fno-strict-aliasing -DNDEBUG -UDEBUG -DANDROID -fmessage-length=0
-W -Wall -Wno-unused -Winit-self -Wpointer-arith -Wsign-promo -DNDEBUG -UDEBUG   -DLIBUTILS_NATIVE=1  –fpermissive     -MD -o out/host/linux-x86/obj/STATIC_LIBRARIES/libutils_intermediates/AssetDir.o frameworks/base/libs/utils/AssetDir.cpp
g++: error: –fpermissive: No such file or directory
make: *** [out/host/linux-x86/obj/STATIC_LIBRARIES/libutils_intermediates/AssetDir.o] Error 1

问题解决方法是：

因为–fpermissive 前边的－是带输入法的，改为不带输入法的 短线就可以了

转载于：http://www.cnblogs.com/lu-yang/archive/2011/11/24/2261282.html

在oc中经常会遇到expected specifier-qualifier-list before sth之类得编译错误，造成这种错误得主要原因就是使用了未被定义的变量。关于specifier-qualifier-list的定义：It's a list of specifiers and qualifiers :-) Specifiers are things like void, char, struct Foo, etc., and qualifiers are keywords like const and volatile. See this C grammar for the definition.如：

typedef struct { char *key; long canTag; long canSet; long allowMultiple; confType *next; } confType;

1.

typedef struct confType { char *key; long canTag; long canSet; long allowMultiple; struct confType*next; } confType;

typedef structconfType confType;  struct confType { char *key; long canTag; long canSet; long allowMultiple; confType *next; };

转：http://blog.yikuyiku.com/?p=2659

基本上，在Makefile里会用到install，其他地方会用cp命令。

它们完成同样的任务——拷贝文件，它们之间的区别主要如下：

1、最重要的一点，如果目标文件存在，cp会先清空文件后往里写入新文件，而install则会先删除掉原先的文件然后写入新文件。这是因为往正在 使用的文件中写入内容可能会导致一些问题，比如说写入正在执行的文件可能会失败，比如说往已经在持续写入的文件句柄中写入新文件会产生错误的文件。而使用 install先删除后写入（会生成新的文件句柄）的方式去安装就能避免这些问题了；

2、install命令会恰当地处理文件权限的问题。比如说，install -c会把目标文件的权限设置为rwxr-xr-x；

3、install命令可以打印出更多更合适的debug信息，还会自动处理SElinux上下文的问题。

转：http://blog.csdn.net/stevenliyong/article/details/4663583

install  - copy files and set attributes

install 在做拷贝的同时，设置attributes.

因此Makefile 中尽量使用install 命令。

例如

@install -d /usr/bin

@install -p -D -m 0755 targets /usr/bin

相当于

@mkdir -p /usr/bin

@cp targets /usr/bin

@chmod 755 /usr/bin/targets

@touch /usr/bin/tagets       <---- 更新文件时间戳

install 命令好强大啊。

另外@前缀的意思是不在控制台输出结果。

转载:http://www.cnblogs.com/wwwsinagogogo/archive/2011/08/15/2139124.html

在源代码里面如果这样是定义的： 
#ifdef   MACRONAME 
//可选代码 
#endif

那在makefile里面 
gcc   -D   MACRONAME=MACRODEF 
或者 
gcc   -D   MACRONAME

这样就定义了预处理宏，编译的时候可选代码就会被编译进去了。

对于GCC编译器，有如下选项： 
        -D macro=string，等价于在头文件中定义：#define   macro   string。例如：-D TRUE=true，等价于：#define   TRUE   true
        -D macro，等价于在头文件中定义：#define   macro   1，实际上也达到了定义：#define   macro的目的。例如：-D LINUX，等价于：#define   LINUX   1（与#define   LINUX作用类似）。
        --define-macro   macro=string与-D macro=string作用相同。

如：

TEST.C 文件   #include <stdio.h> #include <stdlib.h>  main() { #ifdef p1   printf("Hello p1"); #else   printf("Hello p2"); #endif    } 

1.

编译： gcc -o test test.c

运行： ./test

输出： Hello p2

2.

编译： gcc -o test test.c -D p1

运行： ./test

输出： Hello p1

还有另外一种使用方式：

Makefile写法：

$(SERVER_NAME):$(SERVER_OBJ) $(COM_OBJS) 	$(CC) -Wall -pthread -D KRC_SERVER_NAME=$(SERVER_NAME)_FLAG

C代码中用法：

#if KRC_SERVER_NAME == krc_search_FLAG #elif KRC_SERVER_NAME == krc_feedback_FLAG #else #endif  注意：其中的两个参数为宏定义，不能使用常量定义，因为需要在预编译阶段就要确定其值！ #define krc_search_FLAG     1 #define krc_feedback_FLAG   2

这种用法也能实现条件编译的作用，而且更好！

一、程序编译链接的整体流程

二、目标文件的样子（以linux下的elf文件格式为例）

三、静态链接

四、装载

五、动态链接

一、程序编译链接的整体流程

通常我们使用gcc来生成可执行程序，命令为：gcc hello.c，默认生成可执行文件a.out

其实编译（包括链接）的命令：gcc hello.c 可分解为如下4个大的步骤：

• 预处理(Preprocessing)
• 编译(Compilation)
• 汇编(Assembly)
• 链接(Linking)

gcc compilation

1.       预处理(Preproceessing)

预处理的过程主要处理包括以下过程：

• 将所有的#define删除，并且展开所有的宏定义
• 处理所有的条件预编译指令，比如#if #ifdef #elif #else #endif等
• 处理#include 预编译指令，将被包含的文件插入到该预编译指令的位置。
• 删除所有注释 “//”和”/* */”.
• 添加行号和文件标识，以便编译时产生调试用的行号及编译错误警告行号。
• 保留所有的#pragma编译器指令，因为编译器需要使用它们

通常使用以下命令来进行预处理：

gcc -E hello.c -o hello.i

参数-E表示只进行预处理 或者也可以使用以下指令完成预处理过程

cpp hello.c > hello.i      /*  cpp – The C Preprocessor  */

直接cat hello.i 你就可以看到预处理后的代码

2.       编译(Compilation)

编译过程就是把预处理完的文件进行一系列的词法分析，语法分析，语义分析及优化后生成相应的汇编代码。

$gcc –S hello.i –o hello.s

或者

$ /usr/lib/gcc/i486-linux-gnu/4.4/cc1 hello.c

注：现在版本的GCC把预处理和编译两个步骤合成一个步骤，用cc1工具来完成。gcc其实是后台程序的一些包装，根据不同参数去调用其他的实际处理程序，比如：预编译编译程序cc1、汇编器as、连接器ld

3.       汇编(Assembly)

汇编器是将汇编代码转变成机器可以执行的命令，每一个汇编语句几乎都对应一条机器指令。汇编相对于编译过程比较简单，根据汇编指令和机器指令的对照表一一翻译即可。

$ gcc –c hello.c –o hello.o

或者

$ as hello.s –o hello.co

由于hello.o的内容为机器码，不能以普通文本形式的查看（vi 打开看到的是乱码）。

4.       链接(Linking)

通过调用链接器ld来链接程序运行需要的一大堆目标文件，以及所依赖的其它库文件，最后生成可执行文件。

ld -static crt1.o crti.o crtbeginT.o hello.o -start-group -lgcc -lgcc_eh -lc-end-group crtend.o crtn.o (省略了文件的路径名)。

helloworld的大体编译和链接过程就是这样了，那么编译器和链接器到底做了什么呢？

编译过程可分为6步：扫描（词法分析）、语法分析、语义分析、源代码优化、代码生成、目标代码优化。

词法分析：扫描器（Scanner）将源代的字符序列分割成一系列的记号（Token）。lex工具可实现词法扫描。

语法分析：语法分析器将记号（Token）产生语法树（Syntax Tree）。yacc工具可实现语法分析(yacc: Yet Another Compiler Compiler)。

语义分析：静态语义（在编译器可以确定的语义）、动态语义（只能在运行期才能确定的语义）。

源代码优化：源代码优化器(Source Code Optimizer)，将整个语法书转化为中间代码（Intermediate Code）（中间代码是与目标机器和运行环境无关的）。中间代码使得编译器被分为前端和后端。编译器前端负责产生机器无关的中间代码；编译器后端将中间代码转化为目标机器代码。

目标代码生成：代码生成器(Code Generator).

目标代码优化：目标代码优化器(Target Code Optimizer)。

链接的主要内容是把各个模块之间相互引用的部分处理好，使得各个模块之间能够正确地衔接。

链接的主要过程包括：地址和空间分配（Address and Storage Allocation），符号决议（Symbol Resolution），重定位（Relocation）等。

链接分为静态链接和动态链接。

静态链接是指在编译阶段直接把静态库加入到可执行文件中去，这样可执行文件会比较大。

而动态链接则是指链接阶段仅仅只加入一些描述信息，而程序执行时再从系统中把相应动态库加载到内存中去。

静态链接的大致过程如下图所示：

二、目标文件的样子（以linux下的elf文件格式为例）

 

夹在ELF头和节头部表之间的都是节。一个典型的ELF可重定位目标文件包含下面几个节：

• .text：已编译程序的机器代码。
• .rodata：只读数据，比如printf语句中的格式串和开关（switch）语句的跳转表。
• .data：已初始化的全局C变量。局部C变量在运行时被保存在栈中，既不出现在.data中，也不出现在.bss节中。
• .bss：未初始化的全局C变量。在目标文件中这个节不占据实际的空间，它仅仅是一个占位符。目标文件格式区分初始化和未初始化变量是为了空间效率在：在目标文件中，未初始化变量不需要占据任何实际的磁盘空间。
• .symtab：一个符号表（symbol table），它存放在程序中被定义和引用的函数和全局变量（包括引用到的外部变量和函数，不含有局部变量）的信息。一些程序员错误地认为必须通过-g选项来编译一个程序，得到符号表信息。实际上，每个可重定位目标文件在.symtab中都有一张符号表。然而，和编译器中的符号表不同，.symtab符号表不包含局部变量的表目。
• .rel.text：当链接噐把这个目标文件和其他文件结合时，.text节中的许多位置都需要修改。一般而言，任何调用外部函数或者引用全局变量（包括本目标文件内的全局变量，因为在链接时要多个目标文件的相同段合并，这样数据的地址就会改变，所以要重定位）的指令都需要修改。另一方面调用本地函数的指令则不需要修改。注意，可执行目标文件中并不需要重定位信息，因此通常省略，除非使用者显式地指示链接器包含这些信息。
• .rel.data：被模块定义或引用的任何全局变量的信息。一般而言，任何已初始化全局变量的初始值是全局变量或者外部定义函数的地址都需要被修改。
• .debug：一个调试符号表，其有些表目是程序中定义的局部变量和类型定义，有些表目是程序中定义和引用的全局变量，有些是原始的C源文件。只有以-g选项调用编译驱动程序时，才会得到这张表。
• .line：原始C源程序中的行号和.text节中机器指令之间的映射。只有以-g选项调用编译驱动程序时，才会得到这张表。
• .strtab：一个字符串表，其内容包括.symtab和.debug节中的符号表，以及节头部中的节名字。字符串表就是以null结尾的字符串序列。

旁注：为什么未初始化的数据称为.bss?

        用术语.bss来表示未初始化的数据是很普遍的。它起始于IBM 704汇编语言（大约在1957年）中”块存储开始（Block Storage Start）“指令的首字母缩写，并沿用至今。一个记住区分.data和.bss节的简单方法是把“bss”看成是“更好地节省空间（Better Save Space）！“的缩写。

三、静态链接

虚拟存储器是建立在主存--辅存物理结构基础上，有附加的硬件装置及操作系统存储管理软件组成的一种存储体系。

 

顾名思义，虚拟存储器是虚拟的存储器，它其实是不存在的，而仅仅是由一些硬件和软件管理的一种“系统”。他提供了三个重要的能力：1，它将主存看成一个存储在磁盘上的地址空间的高速缓存，在主存中只保存活动区域，并根据需要在磁盘和主存之间来回传送数据（这里存在“交换空间”以及“页面调度”等概念），通过这种方式，高效地利用主存；2，它为每个进程提供了统一的地址空间（以虚拟地址编址），从而简化了存储器管理；3，操作系统会为每个进程提供独立的地址空间，从而保护了每个进程的地址空间不被其他进程破坏。 

虚拟存储器与虚拟地址空间是两个不同的概念：虚拟存储器是假想的存储器，而虚拟存储空间是假想的内存。它们之间的关系应该与主存储器与内存空间之间的关系类似。

链接部分：

链接就是将不同部分的代码和数据收集和组合成一个单一文件的过程，也就是把不同目标文件合并成最终可执行文件的过程。当然，务必知道：这个过程不涉及内存。链接可以分为三种情形：1，编译时链接，也就是我们常说的静态链接；2，装载时链接；3，运行时链接。装载时链接和运行时链接合称为动态链接。在此，我们的链接部分将主要讲述静态链接，而装载时链接我们放在装载部分讲，运行时链接忽略。

 

 

1、什么是静态链接？

静态链接就是将多个目标文件组合在一起形成一个可执行文件，如将a.o 和 b.o 链接在一起形成 可执行文件ab。

2、静态链接的过程包括哪几个部分？

      静态链接包括两个大部分：一是空间和地址的分配；二是符号解析和重定位

 

（1）空间和地址的分配

编译器在将a.o 和 b.o 是如何合并在一起的？？

第二种方法就是 相似段合并：顾名思义 就是把不同目标文件的相同名字的段合并成一个段，如下图：

　　　　　　　　　　　　　　　　　　　　　　图1

这是编译器实际进行合并目标文件的策略。

/*a.c*/
extern int shared; int main() { int a = 100; swap(&a,&shared); }

/*b.c*/
int shared = 1; void swap(int *a,int *b) {    *a ^= *b ^= *a ^= *b; }  

编译这两个文件得到“a.o”和“b.o”两个目标文件

§gcc -c a.c b.c

从代码中可以看到三个符号：share，swap和main。

静态链接的整个过程分为两步:
 

第一步：空间和地址分配。扫描所有的输入目标文件，获得他们的各个段的长度、属性和位置，并且将输入目标文件中的符号表中所有的符号定义和符号引用收集起来，统一放到一个全局符号表。这样，连接器将能够获得所有输入目标文件的段长度，并且将它们合并，计算出输出文件中各个段合并后的长度与位置，并建立映射关系。

这里可能会有一个问题：建立了什么样的映射关系。如上面的图1，你可能就会有所了解。映射关系就是指可执行文件与进程虚拟地址空间之间的映射。那么，这里程序还没有执行，更不会出现进程，哪里来的进程地址空间呢？此时虚拟存储器便发挥了很大的作用：虽然此时没有进程，但是每个进程的虚拟地址空间的格式都是一致的。所以，为可执行文件的每个段甚至每个符号符号分配地址也就不会有什么错了。注意：在链接之前，目标文件中的所有段的虚拟地址都是0，因为虚拟空间还没有被分配，默认都为0.等到链接之后，可执行文件中的各个段已经都被分配到了相应的虚拟地址

第二步：符号解析与重定位

首先，符号解析。解析符号就是将每个符号引用与它输入的可重定位目标文件中的符号表中的一个确定的符号定义联系起来。

若找不到，则出现编译时错误。   

其次是重定位；

不同的处理器指令对于地址的格式和方式都不一样。我们这里采用的是32位的x86处理器，介绍两种寻址方式。

X86基本重定位类型
宏定义	值	重定位修正方法
R_386_32	1	绝对寻址修正S + A
R_386_PC32	2	相对寻址修正S + A - P

注：

A：保存在被修正位置的值，对于32位cpu的话，采用
R_386_PC32寻址的话
它应该为0xFFFFFFFC即-4，它是代表地址的四个字节；而采用
R_386_32寻址，它应该为0.

P：被修正的位置。考虑以下程序

...

1023: 11 11 11

1026:e8 
fc
 ff ff ff

102b: 11 11 11

...

上述蓝色fc标记处即是被修正的位置，即0x1027.

S：符号的实际地址。也就是第一步中空间和地址分配时得到的符号虚拟地址。

举例来说吧！链接成的可执行文件中，假设main函数的虚拟地址为0x1000，swap函数的虚拟地址为0x2000；shared变量的虚拟地址为0x3000;

绝对地址修正：对shared变量的地址修正。

l 
S：shared的实际地址为0x3000；

l 
A：被修正位置的值，即0.

所以最后这个重定位修正地址为：0x3000，不变！

相对寻址修正：对符号“swap”进行修正。

l 
S：符号swap的实际地址，即0x2000；

l 
A：被修正位置的值，即0xFFFFFFFC（-4）；

l 
P：被修正位置，及0x1027

最后的重定位修正地址为：S + A -P = 0x2000 +（-4）- 0x1027 = 0xFD5.即修正后的程序为：

...

1023: 11 11 11

1026:e8 
d5 0f 00 00

102b: 11 11 11

...

发现熟悉的规则了吗？下一条指令（PC）的地址为0x102b，加上这个修正值正好等于0x2000，

0x102b + 0xFD5 = 0x2000，刚好是swap函数的地址。

 

 

以上内容没有涉及到c标准库，仅仅是自己实现的两个c语言程序之间的链接状况，也就是“程序里面的printf怎么处理”没有说明。这里，我们就要提及“静态库”的概念。其实一个静态库可以简单地看成一组目标文件的集合，即很多目标文件经过压缩打包后形成的一个文件。与静态库链接的过程是这样的：ld链接器自动查找全局符号表，找到那些为决议的符号，然后查出它们所在的目标文件，将这些目标文件从静态库中“解压”出来，最终将它们链接在一起成为一个可执行文件。也就是说只有少数几个库和目标文件被链接入了最终的可执行文件，而非所有的库一股脑地被链接进了可执行文件。

 

四、装载：

以Linux内核装载ELF为例简述一下装载过程。当我们在Linux系统的bash下输入一个命令执行某个ELF程序时，在用户层面，bash进程会调用fork()系统调用创建一个新的进程，然后新的进程调用execve()来执行指定的ELF文件，原先的bash进程继续返回等待刚才启动时新进程结束，然后继续等待用户输入命令。这里需注意，随着一个新进程的出现，操作系统会为它创建一个独立的虚拟地址空间。

【创建虚拟地址空间】我们知道一个虚拟空间由一组映射函数将虚拟空间的各个页映射到相应的物理空间，那么创建一个虚拟空间实际上并不是创建空间而是创建映射函数所需要的数据结构。举例来说，在x86的Linux下创建虚拟地址空间实际上只是分配一个页目录（页表）就可以了，甚至不设置页映射关系，这些映射关系等到后面程序发生“缺页”时在进行设置。

在进入execve()系统调用之后，Linux内核就开始进行真正的装载工作。在内核中，execve()系统调用相应的入口是sys_execve(),作用：参数的检查复制；调用do_execve(),流程：查找被执行的文件，读取文件的前128个字节以判断文件的格式是elf还是其它；调用search_binary_handle(),流程：通过判断文件头部的魔数确定文件的格式，并且调用相应的装载处理程序。ELF可执行文件的装载处理过程叫load_elf_binary(),它的主要步骤如下：

1，检查ELF可执行文件格式的有效性，比如魔数、程序头表中段的数量。

2，寻找动态链接的“.interp”段，找到动态链接器的路径，以便于后面动态链接时会用上。

3，读取可执行文件的程序头，并且创建虚拟空间与可执行文件的映射关系。

【读取可执行文件的程序头（存储了哪些部分被映射），并且创建虚拟空间与可执行文件的映射关系】创建虚拟空间时的页映射关系函数是虚拟空间到物理内存的映射关系，而这一步所做的事虚拟空间与可执行文件的映射关系。我们知道，当程序发生缺页是，操作系统会为物理内存分配一个物理页，然后将该缺页从磁盘中读取到内存，在设置缺页的虚拟页与物理页之间的映射关系，这样程序才可以得以正常运行。但是明显的一点是，当操作系统捕获到缺页错误时，他应当知道程序当前需要的页在可执行文件中的哪一个位置。而这就是虚拟存储与可执行文件之间的映射关系。实际上，这种映射关系仅仅是保存在操作系统内部的一个数据结构。当发生缺页错误是，CPU将控制权交给操作系统，操作系统利用专门的缺页处理例程来查询这个数据结构（映射关系），然后找到所需页所在的虚拟内存区域，以及在可执行文件的偏移，然后把该页加载进物理内存，同时将该虚拟页与物理页之间建立映射关系，最后把控制权还给进程，进程从刚才缺页位置重新开始执行。

4，初始化ELF进程环境。

5，将系统调用的返回地址修改成ELF可执行文件的入口点，这个入口点取决于程序的链接方式，对于静态链接的ELF可执行文件，它就是ELF文件的文件头中e_entry所指的地址；对于动态链接的ELF可执行文件，程序入口点就是动态链接器。

【将CPU指令寄存器设置成可执行文件的入口，启动运行】对动态链接来讲，此时就启动了动态链接器。

当load_elf_binary()执行完毕，返回至do_execve()在返回至sys_execve()时，系统调用的返回地址已经被改写成了被装载的ELF程序的入口地址了。所以，当sys_execve()系统调用从内核态返回到用户态时，EIP寄存器直接跳转到ELF程序的入口地址。此时，ELF可执行文件装载完成。接下来就是动态链接器对程序进行动态链接了。

 

进程的虚拟空间：

五、动态链接

动态链接ELF文件的生成过程

主要原因有两个：第一，考虑内存和磁盘空间。静态链接极大地浪费内存空间。因为在静态链接的情况下，假设有两个程序共享一个模块，那么在静态链接后输出的两个可执行文件中各有一个共享模块的副本。如果同时运行这两个可执行文件，那么这个共享模块将在磁盘和内存中都有两个副本，对磁盘和内存造成极大地浪费；第二，程序的更新。一旦程序中的一个模块被修改，那么整个程序都要重新链接、发布给用户。如果这个程序相当的大，那么后果就会更加严重！

 对于一个共享对象（linux下共享的模块），要实现被其他程序之间的共享，就要使其代码和数据分开，每个程序都会有该模块的数据部分的副本，代码部分是共享的。

共享模块被映射的虚拟地址空间就在上面进程虚拟空间中的 （Memery Mapping部分）

共享模块被映射的模样是

 

 

动态链接做了什么？

务必知道，动态链接是相对于共享对象而言的。动态链接器将程序所需要的所有共享库装载到进程的地址空间，并且将程序汇总所有为决议的符号绑定到相应的动态链接库（共享库）中，并进行重定位工作。

对于共享模块来说，要实现共享，那么其代码对数据的访问必须是地址无关（就是代码中的地址是固定的，当然这是用的相对地址喽）的，如何做到地址无关，编译器是这么干的，每一个共享模块，都会在其代码段有一个GOT(global offset table)段，如上图所示，Got是一个指针数组，用来存储外部变量的地址，而代码相对于Got的距离是固定的，当对外部模块变量数据和函数进行访问时，就去访问变量在GOT中的位置。

共享模块对于数据的访问方式：

本模块的全局变量和函数------相对地址

外模块的全局变量和函数-------GOT段

动态链接重定位时修改GOT中的值就实现了对变量的正确访问。

 

 

动态链接的ELF文件启动过程

动态链接基本分为三步：先是启动动态链接器本身，然后装载所有需要的共享对象，最后重定位和初始化。

1，动态链接器自举

就我们所知道的，对普通的共享对象文件来说，它的重定位工作是由动态链接器来完成；它也可以依赖于其他共享对象，其中被依赖的共享对象由动态链接器负责链接和装载。那么，对于动态链接器本身呢，它也是一个共享对象，它的重定位工作由谁完成？它是否可以依赖于其他的共享对象文件？

动态链接器有其自身的特殊性：首先，动态链接器本身不可以依赖其他任何共享对象（人为控制）；其次动态链接器本身所需要的全局和静态变量的重定位工作由它自身完成（自举代码）。

我们知道，在Linux下，动态链接器ld.so实际上也是一个共享对象，操作系统同样通过映射的方式将它加载到进程的地址空间中。操作系统在加载完动态链接器之后，就将控制权交给动态链接器。动态链接器入口地址即是自举代码的入口。动态链接器启动后，它的自举代码即开始执行。自举代码首先会找到它自己的GOT(全局偏移表，记录每个段的偏移位置）。而GOT的第一个入口保存的就是“.dynamic”段的偏移地址，由此找到动态链接器本身的“.dynamic”段。通过“.dynamic”段中的信息，自举代码便可以获得动态链接器本身的重定位表和符号表等，从而得到动态链接器本身的重定位入口，然后将它们重定位。完成自举后，就可以自由地调用各种函数和全局变量。

2，装载共享对象

完成自举后，动态链接器将可执行文件和链接器本身的符号表都合并到一个符号表当中，称之为“全局符号表”。然后链接器开始寻找可执行文件所依赖的共享对象：从“.dynamic”段中找到DT_NEEDED类型，它所指出的就是可执行文件所依赖的共享对象。由此，动态链接器可以列出可执行文件所依赖的所有共享对象，并将这些共享对象的名字放入到一个装载集合中。然后链接器开始从集合中取出一个所需要的共享对象的名字，找到相应的文件后打开该文件，读取相应的ELF文件头和“.dynamic”，然后将它相应的代码段和数据段映射到进程空间中。如果这个ELF共享对象还依赖于其他共享对象，那么将依赖的共享对象的名字放到装载集合中。如此循环，直到所有依赖的共享对象都被装载完成为止。

当一个新的共享对象被装载进来的时候，它的符号表会被合并到全局符号表中。所以当所有的共享对象都被装载进来的时候，全局符号表里面将包含动态链接器所需要的所有符号。

3，重定位和初始化

当上述两步完成以后，动态链接器开始重新遍历可执行文件和每个共享对象的重定位表，将表中每个需要重定位的位置进行修正，原理同前。

重定位完成以后，如果某个共享对象有“.init”段，那么动态链接器会执行“.init”段中的代码，用以实现共享对象特有的初始化过程。

此时，所有的共享对象都已经装载并链接完成了，动态链接器的任务也到此结束。同时装载链接部分也将告一段落！接下来便是程序的执行了。。。

1.       GNU的make工作时的执行步骤入下：

1.         读入所有的Makefile。

2.         读入被include的其它Makefile。

3.         初始化文件中的变量。

4.         推导隐晦规则，并分析所有规则。

5.         为所有的目标文件创建依赖关系链。

6.         根据依赖关系，决定哪些目标要重新生成。

7.         执行生成命令。

2.      .PHONY 指明后面为伪目标

.SILENT 相当于make的-s参数，在执行前不显示要执行的命令

.IGNORE 相当于make的-i参数，当检测到错误，继续执行其他命令

make –n 参数，读取规则并显示，但是不执行

gcc –M 由编译器自动生成依赖关系

3.       判断：ifeq/ ifneq/ ifdef/ ifndef

ifeq ($(CC),gcc)

             $(CC) -o foo $(objects) $(libs_for_gcc)

       else

             $(CC) -o foo $(objects) $(normal_libs)

       endif

4.       可识别的后缀指的是特殊目标“.SUFFIXES”的所有依赖的名字。通过给特殊目标“SUFFIXES”添加依赖来增加一个可被识别的后缀：

 .SUFFIXES: .hack .win

它所实现的功能是把后缀“.hack”和“.win”加入到可识别后缀列表的末尾。

如果需要重设默认所有的可识别后缀，可以这样来实现：

.SUFFIXES:          #删除所有已定义的可识别后缀

.SUFFIXES: .c .o .h   #重新定义

5.       -include filename，包含文件

6.       -M 生成文件的关联的信息，这样就可以知道源代码文件里面关联了哪些它所依赖的头文件。

-MD 跟-M相当，但是输出导入到.d文件中，如gcc -MD test.c，刚输出的依赖关系存放在test.d文件里。

7.       $@ 代表规则中的目标文件名

$< 规则的第一个依赖文件名。如果是隐含规则，则它代表通过目标指定的第一个依赖文件。

$^ 规则的所有依赖文件列表，使用空格分隔。

8.       我们可以使用最终万用规则来实现。例如：在调试Makefile时（可能一些源文件还没有完成），我们所关心的是Makefile中规则的正确执行，而不关心源文件的内容。

 %::

    touch $@

9.       列出当前目录下所有符合模式“PATTERN”格式的文件名。

返回值：空格分割的、存在当前目录下的所有符合模式“PATTERN”的文件名。

 $(wildcard *.c)

 返回值为当前目录下所有.c源文件列表。

10.    目标总会被认为是最新的。就是说：这个规则一旦被执行，make就认为它的目标已经被更新过 

clean: FORCE

rm $(objects)

FORCE:

11.    subsystem:

           cd subdir && $(MAKE)

 其等价于规则：

 subsystem:

     $(MAKE) -C subdir

规则中“$(MAKE)”是对变量“MAKE" 的引用。第一个规则命令的意思是：进入子目录，然后在子目录下执行make。第二个规则时用了make的“-C”选项，同样是首先进入子目录而后再执行make。

12.    -w选项

在多级make递归调用过程中，选项“-w”或者“--print-directory”可以让make在开始编译一个目录之前和完成此目录的编译之后给出相应的提示信息

以下是自己写的一个Makefile，目录结构为模块目录下存在inc、src、obj三个目录。由于用到了隐式规则，存在目录的一些限制，当前巴该Makefile放到子目录obj下：

====================================================

vpath %.c ../src

INCLUDE=../inc

CC=gcc

CFLAGS=-g -I$(INCLUDE)

TARGET=lib.a

DEPENDFILE=depend.dep

SRC_DIR=$(wildcard ../src/*.c)

OBJS=$(patsubst %.c,%.o,$(notdir $(SRC_DIR)))

all:$(TARGET)

$(TARGET):$(DEPENDFILE) $(OBJS)

 ar -crv $@ $(OBJS)

$(DEPENDFILE):

 $(CC) -M -I$(INCLUDE) $(SRC_DIR) > $@

.PHONY:clean

clean:

 rm -rf $(TARGET) *.o $(DEPENDFILE)

-include depend.*

====================================================

Makefile", line 1: make: Dependency line needs colon or double colon operator.
"Makefile", line 7: make: Dependency line needs colon or double colon operator.
", line 0: make: Cannot open /gboss/anta32/stdmake/stdenv
"Makefile", line 10: make: Dependency line needs colon or double colon operator.
"Makefile", line 13: make: Dependency line needs colon or double colon operator.
"Makefile", line 14: make: Dependency line needs colon or double colon operator.
"Makefile", line 18: make: Dependency line needs colon or double colon operator.
"Makefile", line 21: make: Dependency line needs colon or double colon operator.
"Makefile", line 24: make: Dependency line needs colon or double colon operator.
"Makefile", line 28: make: Dependency line needs colon or double colon operator

......

原来是上传文件时的编码没有设置好，要用asc进行编码。重新上传后，正常。

IP1   = /ZDZ_UAT/usr/sqllib/include
LP1   = /ZDZ_UAT/usr/sqllib/lib
LIB1  = db2

DATABASE = mydb
USER = 1111
PASSWD = 1111

EXE = myfirst

SQC = myfirst.sqc
CFILE = myfirst.c
BND = myfirst.bnd
OBJ = myfirst.o

all : $(EXE)

$(EXE) : $(OBJ)
        $(CC) $(CFLAGS) -L$(LP1) $(OBJ) -o $@ -l$(LIB1);

$(OBJ) : $(CFILE)
        $(CC) -g -c $(CFLAGS) -I$(IP1) $(CFILE)

$(CFILE) $(BND) : $(SQC)
        $(DB2) connect to $(DATABASE) user $(USER) using $(PASSWD) ;\
        $(DB2) prep $(SQC) bindfile ;\
        $(DB2) bind $(BND); \
        $(DB2) connect reset
clean :
        rm $(CFILE) $(BND) $(OBJ) $(EXE)

IP1   = /home/ppqf_sd/sqllib/include
LP1   = /home/ppqf_sd/sqllib/lib
LIB1  = db2

DATABASE = mydb
USER = ppqf_sd
PASSWD = ppqf_sd

EXE = myfirst

SQC = myfirst.sqc
C   = myfirst.c
BND = myfirst.bnd
OBJ = myfirst.o

all : $(EXE)

$(EXE) : $(OBJ)
        $(CC) $(CFLAGS) -L$(LP1) $(OBJ) -o $@ -l$(LIB1);

$(OBJ) : $(C)
        $(CC) -g -c $(CFLAGS) -I$(IP1) $(C)

$(C) $(BND) : $(SQC)
        $(DB2) connect to $(DATABASE) user $(USER) using $(PASSWD) ;/
        $(DB2) prep $(SQC) target cplusplus bindfile using $(BND) ;/
        $(DB2) bind $(BND); /
        $(DB2) connect reset
clean :
        rm $(C) $(BND) $(OBJ) $(EXE)