其他内容整理如下（原作者未知):

nm用于列出目标文件的符号清单，如果没有指定目标文件，则默认为“a.out”。nm的格式如下：

nm [‘-a’|‘--debug-syms’] [‘-g’|‘--extern-only’]
         [‘-B’] [‘-C’|‘--demangle’[=style]] [‘-D’|‘--dynamic’]
         [‘-S’|‘--print-size’] [‘-s’|‘--print-armap’]
         [‘-A’|‘-o’|‘--print-file-name’][‘--special-syms’]
         [‘-n’|‘-v’|‘--numeric-sort’] [‘-p’|‘--no-sort’]
         [‘-r’|‘--reverse-sort’] [‘--size-sort’] [‘-u’|‘--undefined-only’]
         [‘-t’ radix|‘--radix=’radix] [‘-P’|‘--portability’]
         [‘--target=’bfdname] [‘-f’format|‘--format=’format]
         [‘--defined-only’] [‘-l’|‘--line-numbers’] [‘--no-demangle’]
        [‘-V’|‘--version’] [‘-X 32_64’] [‘--help’] [objfile...]
  
对于每一个符号，nm列出其值(the symbol value)，类型（the symbol type）和其名字(the symbol name)。
如下例：
  
     00000024 T cleanup_before_linux
     00000018 T cpu_init
     00000060 T dcache_disable
     00000054 T dcache_enable
     0000006c T dcache_status
     00000000 T do_reset
     0000003c T icache_disable
     00000030 T icache_enable
     00000048 T icache_status
 
上面的显示是使用nm cpu.o的输出，对于cleanup_before_linux这个符号来说，00000024是以16进制显示的其值，T为其类型，而cleanup_before_linux是其名字。可以看出，上面显示的cleanup_before_linux这个symbol的值实际上是该函数在text section中的偏移。但是，每个符号的值的具体含义依其类型而异。当然，对于每个符号的值，其类型、其值以及它们所属的section是密切相关的。
下面说明符号类型：对于每一个符号来说，其类型如果是小写的，则表明该符号是local的；大写则表明该符号是global(external)的。

[root@~]# diff -urNa dir1 dir2
　　-a Treat all files as text and compare them line-by-line, even if they do not seem to be text.
　　-N, --new-file
　　　　In directory comparison, if a file is found in only one directory, treat it as present but empty in the other directory.
　　-r When comparing directories, recursively compare any subdirectories found.

　　-u Use the unified output format.

比较文件夹diff，也可以比较文件MD5列表。下面命令可以获取文件夹中文件md5列表

find /home/ -type f -not \( -name '.*' \) -exec md5sum {} \;

说明：(1) /home/文件目录

　　   (2) -type f 文件类型为普通文件

　　   (3) -not \( -name '.*' \)  过滤掉隐藏文件。可以过滤掉不需要考虑的文件

         (4) -exec md5sum {} \;  对每个文件执行md5sum命令 

 用tar命令压缩后，比较文件的MD5是不行的。tar压缩会带上文件的时间

在网上查找资料后，解决方法如下。

1.查看gcc版本中包含哪些库。

strings /usr/lib64/libstdc++.so.6 | grep GLIBC

　　可以看出不包含GLIBCXX_3.4.14

2.从网上下载高版本的libstdc++.so.6.0.13以上的版本，比如libstdc++.so.6.0.17。

3.把libstdc++.so.6.0.17拷贝到/usr/lib64目录下。

　　cp libstdc++.so.6.0.17 /usr/lib64/

4.删除libstdc++.so.6符号连接。

　　rm libstdc++.so.6

5.新建里符号连接。

　　ln -s libstdc++.so.6.0.17 libstdc++.so.6

6.再次查看就没有问题了。

libstdc++.so.6.0.17下载地址

http://unix.stackexchange.com/questions/74646/difference-between-lib-lib32-lib64-libx32-and-libexec

#include <stdio.h>

 

const char* sz_static = "i'm a static str.";

 

void print_niuzai_said()
{
    printf("in static lib, niu zai said, i'm happy!\n");
}

#include <stdio.h>
#include "static.h"

 

void print_papa_said()
{
    print_niuzai_said();
    printf("in dynamic lib, papa said, niu zai is wonderful!\n");
}

 

#include <unistd.h>
#include "dynamic.h"

 

int main(int argc, char** argv)
{
    print_papa_said();
    return 0;
}

1、使用 "gcc -o libdynamic.so -shared -fPIC -L. -lstatic dynamic.o "，连接成功，但.so里实际上没有static.o里的内容。

2、使用"gcc -o libdynamic.so dynamic.o -shared -fPIC -L. -lstatic",连接失败 

 

 

当你在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

1. (.text+0x13): undefined reference to `func' 

    关于undefined reference这样的问题，大家其实经常会遇到，在此，我以详细地示例给出常见错误的各种原因以及解决方法，希望对初学者有所帮助。

1.  链接时缺失了相关目标文件（.o）

    测试代码如下：

    然后编译。

1. gcc -c test.c  
2. gcc –c main.c 

    得到两个 .o 文件，一个是 main.o，一个是 test.o ，然后我们链接 .o 得到可执行程序：

1. gcc -o main main.o 

    这时，你会发现，报错了：

1. main.o: In function `main':  
2. main.c:(.text+0x7): undefined reference to `test'  
3. collect2: ld returned 1 exit status 

    这就是最典型的undefined reference错误，因为在链接时发现找不到某个函数的实现文件，本例中test.o文件中包含了test()函数的实现，所以如果按下面这种方式链接就没事了。

1. gcc -o main main.o test.o 

   【扩展】：其实上面为了让大家更加清楚底层原因，我把编译链接分开了，下面这样编译也会报undefined reference错，其实底层原因与上面是一样的。

1. gcc -o main main.c //缺少test()的实现文件 

需要改成如下形式才能成功，将test()函数的实现文件一起编译。

1. gcc -o main main.c test.c //ok,没问题了 

2.    链接时缺少相关的库文件（.a/.so）

    在此，只举个静态库的例子，假设源码如下。

    先把test.c编译成静态库(.a)文件

1. gcc -c test.c  
2. ar -rc test.a test.o 

    至此，我们得到了test.a文件。我们开始编译main.c

1. gcc -c main.c 

    这时，则生成了main.o文件，然后我们再通过如下命令进行链接希望得到可执行程序。

1. gcc -o main main.o 

    你会发现，编译器报错了：

1. /tmp/ccCPA13l.o: In function `main':  
2. main.c:(.text+0x7): undefined reference to `test'  
3. collect2: ld returned 1 exit status 

    其根本原因也是找不到test()函数的实现文件，由于该test()函数的实现在test.a这个静态库中的，故在链接的时候需要在其后加入test.a这个库，链接命令修改为如下形式即可。

1. gcc -o main main.o ./test.a  //注：./ 是给出了test.a的路径 

     【扩展】：同样，为了把问题说清楚，上面我们把代码的编译链接分开了，如果希望一次性生成可执行程序，则可以对main.c和test.a执行如下命令。

1. gcc -o main main.c ./test.a  //同样，如果不加test.a也会报错 

3.    链接的库文件中又使用了另一个库文件

    这种问题比较隐蔽，也是我最近遇到的与网上大家讨论的不同的问题，举例说明如下，首先，还是看看测试代码。

    从上图可以看出，main.c调用了test.c的函数，test.c中又调用了fun.c的函数。
    首先，我们先对fun.c，test.c，main.c进行编译，生成 .o文件。

1. gcc -c func.c  
2. gcc -c test.c  
3. gcc -c main.c 

    然后，将test.c和func.c各自打包成为静态库文件。

1. ar –rc func.a func.o  
2. ar –rc test.a test.o 

    这时，我们准备将main.o链接为可执行程序，由于我们的main.c中包含了对test()的调用，因此，应该在链接时将test.a作为我们的库文件，链接命令如下。

1. gcc -o main main.o test.a 

    这时，编译器仍然会报错，如下：

1. test.a(test.o): In function `test':  
2. test.c:(.text+0x13): undefined reference to `func'  
3. collect2: ld returned 1 exit status 

    就是说，链接的时候，发现我们的test.a调用了func()函数，找不到对应的实现。由此我们发现，原来我们还需要将test.a所引用到的库文件也加进来才能成功链接，因此命令如下。

1. gcc -o main main.o test.a func.a 

    ok，这样就可以成功得到最终的程序了。同样，如果我们的库或者程序中引用了第三方库（如pthread.a）则同样在链接的时候需要给出第三方库的路径和库文件，否则就会得到undefined reference的错误。

4 多个库文件链接顺序问题

    这种问题也非常的隐蔽，不仔细研究你可能会感到非常地莫名其妙。我们依然回到第3小节所讨论的问题中，在最后，如果我们把链接的库的顺序换一下，看看会发生什么结果？

1. gcc -o main main.o func.a test.a 

    我们会得到如下报错.

1. test.a(test.o): In function `test':  
2. test.c:(.text+0x13): undefined reference to `func'  
3. collect2: ld returned 1 exit status 

    因此，我们需要注意，在链接命令中给出所依赖的库时，需要注意库之间的依赖顺序，依赖其他库的库一定要放到被依赖库的前面，这样才能真正避免undefined reference的错误，完成编译链接。

5. 在c++代码中链接c语言的库

    如果你的库文件由c代码生成的，则在c++代码中链接库中的函数时，也会碰到undefined reference的问题。下面举例说明。

    首先，编写c语言版库文件： 

    编译，打包为静态库：test.a

1. gcc -c test.c  
2. ar -rc test.a test.o 

    至此，我们得到了test.a文件。下面我们开始编写c++文件main.cpp

    然后编译main.cpp生成可执行程序：

1. g++ -o main main.cpp test.a 

    会发现报错：

1. /tmp/ccJjiCoS.o: In function `main': 
2. main.cpp:(.text+0x7): undefined reference to `test()' 
3. collect2: ld returned 1 exit status 

    原因就是main.cpp为c++代码，调用了c语言库的函数，因此链接的时候找不到，解决方法：即在main.cpp中，把与c语言库test.a相关的头文件包含添加一个extern "C"的声明即可。例如，修改后的main.cpp如下：

1. g++ -o main main.cpp test.a 

    再编译会发现，问题已经成功解决。

6.  总 结

    当然，上面几种是我目前发现的比较常见的undefined reference错误的原因和解决方法，可能也有其他各种原因，欢迎大家来信lujun.hust@gmail.com交流，对本文档进行补充，方面新手们解决学习过程中遇到的各种问题。

Undefined reference to 错误:这类错误是在连接过程中出现的，可能有两种原因∶

一是使用者自己定义的函数或者全局变量所在源代码文件，没有被编译、连接，或者干脆还没有定义，这 需要使用者根据实际情况修改源程序，给出全局变量或者函数的定义体；

1) 可以头文件中类加上

　　#ifndef xxx_H
　　#define xxx_H

　　namespace xxx{

　　};

　　#endif

　　cpp文件中包含头文件，using namespace xxx; 或者 其他访问方式（自行百度namepace 使用方法）

2）若全局 namespace xxx 被class xxx 覆盖，请加上::

3) 请注意原来的makefile文件是否包含新增的文件，并且逻辑包含关系正确。

二是未定义的符号是一个标准的库函数，在源程序中使用了该库函数，而连接过程中还没有 给定相应的函数库的名称，或者是该档案库的目录名称有问题.

   在使用厂商新提供的库文件时，遇到了新问题，库中的函数程序不识别，同样的方法在使用以前的库时是可行的，在CSDN上求助并查阅一些资料后，问题已经解决。
1）使用库的时候首先要明确库（或者头文件）是用什么编写的，如果是用C++编写的，那么在MFC中可以直接使用，如果是用c编写的，那么在#include头文件的时候要加上
extern “C”{
#include “OOXX.h”
}
注意格式换行要正确。
2）为什么要如1）中那样操作呢，因为在c++中编译的方法和c不用，这是由于函数的重载造成的。在c中不涉及重载，如函数func（int a，float b）编译成_func.在c++中涉及重载，如果只凭函数名是不足以判断是使用的哪个函数，所以编译的时候要加上变量，如函数func(int a,float b)编译成_func_int_float,这样不但确定了函数名，还确定了使用哪中重载。正式由于以上的不同，使得c中编的函数不能在c++中直接使 用，c++中为了兼容c的代码，提出了extern “C”的方法，在编译声明了extern “C”的函数函数时，会按照c语言的方法编译。
如果不加extern “C”，在编译的时候会出现link错误：error link 2001：unresolved extern symbol “long __stdcall func(int a,float b)@QDASCFQAE@”之类的错误，说明编译器没有识别出函数func

在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; };

在linux的.profile中设置为了export LANG=zh_CN.gbk

在secureCrt，连接该环境的会话中，选择“选项”--“会话选项”-“终端” -“外观”

在字符编码中选择“简体中文GB2313”

原来的选项是“UTF-8”

自己写了一个，先转成16进制，再转成二进制。

也可以先转成8进制，再转成二进制。

我测试环境double是8个字节，64位长度。

*/

/*打印出double在内存的中的每一个二进制位
*/
void DoubleToString(double *p_dl){
       char c_dl_16[16+1];
       char c_dl_64[64+1];
       memset(c_dl_64,'\0',sizeof(c_dl_64));
       unsigned char *t = (unsigned char *)p_dl;
       int charCount = sizeof(double) ;
       memset(c_dl_16,'\0',sizeof(c_dl_16));
       
       if (t == NULL)
       return;
     int i=0;
     for(i=0;i<charCount;i++){
        sprintf(c_dl_16+i*2,"%02x",t[i]);
     }
     /*printf("\n");  */
          printf("[%s]\n",c_dl_16);  
     /*对每一位，将十六进制转换为二进制的字符串*/
     char tmpc[4+1];
     for(int j=0;j<16;j++){
          memset(tmpc,'\0',sizeof(tmpc));
       switch(c_dl_16[j]){
            case '0':
                  memcpy(tmpc,"0000",4);
                  break;
            case '1':
                  memcpy(tmpc,"0001",4);
                  break;
            case '2':
                  memcpy(tmpc,"0010",4);
                  break;                                  
            case '3':
                  memcpy(tmpc,"0011",4);
                  break;  
            case '4':
                  memcpy(tmpc,"0100",4);
                  break;  
            case '5':
                  memcpy(tmpc,"0101",4);
                  break;  
            case '6':
                  memcpy(tmpc,"0110",4);
                  break; 
            case '7':
                  memcpy(tmpc,"0111",4);
                  break; 
            case '8':
                  memcpy(tmpc,"1000",4);
                  break; 
            case '9':
                  memcpy(tmpc,"1001",4);
                  break; 
            case 'a':
                  memcpy(tmpc,"1010",4);
                  break; 
            case 'b':
                  memcpy(tmpc,"1011",4);
                  break;
            case 'c':
                  memcpy(tmpc,"1100",4);
                  break;
            case 'd':
                  memcpy(tmpc,"1101",4);
                  break;
            case 'e':
                  memcpy(tmpc,"1110",4);
                  break;
            case 'f':
                  memcpy(tmpc,"1111",4);
                  break;
       }
       sprintf(c_dl_64+j*4,"%s",tmpc);
     }
     printf("[%s]\n",c_dl_64);
     
}

使用

    double tmpd=0.01;
    DoubleToString(&tmpd);
    printf("%x\n",0.01);

转：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

转自：http://blog.sina.com.cn/s/blog_622a99700100pjv3.html 感谢这位大神，我刚好遇到这个问题

尝试解答以下问题：

     1.为什么cp的方式更新运行中进程的so，程序会coredump

     2.采用什么方式更新已经加载了的so,就可以避免coredump

我们的公共组件绝大部分都支持so形式的自定义插件，比如s++,qzhttp,ttc。在不停进程更新so的时候往往会产生coredump，并且肯定core得莫名其妙，core得让人心碎。

先看一下用cp的方式更新so的时候发生了什么事情

strace cp new.so old.so #strace是人间利器

发现老的so被trunc了，这个过程发生的具体的事情是：

     1.应用程序通过dlopen打开so的时候，kernel通过mmap把so加载到进程地址空间，对应于vma里的几个page.

     2.在这个过程中loader会把so里面引用的外部符号例如malloc printf等解析成真正的虚存地址。

     3.当so被cp覆盖时，确切地说是被trunc时，kernel会把so文件在虚拟内的页purge 掉。

     4.当运行到so里面的代码时，因为物理内存中不再有实际的数据（仅存在于虚存空间内），会产生一次缺页中断。

     5.Kernel从so文件中copy一份到内存中去,a)但是这时的全局符号表并没有经过解析，当调用到时就产生segment fault , b)如果需要的文件偏移大于新的so的地址范围，就会产生buserror.

所以，如果用相同的so去覆盖

     A) 如果so里面依赖了外部符号，coredump

     B) 如果so里面没有依赖外部符号，运气不错，不会coredump

所有问题的产生都是因为so被trunc了一把，所以如果不用turnc的方式就避免这个问题。Ok,该我们的install 上场了。

strace install new.so old.so

install 的方式跟cp不同，先unlink再creat，当unlink的时候，已经map的虚拟空间vma中的inode结点没有变，只有inode结点的引用计数为0是，kernel才把它干掉。

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

二、目标文件的样子（以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”段中的代码，用以实现共享对象特有的初始化过程。

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

首先，原文地址如下：

http://www.quora.com/Systems-Programming/What-is-the-exact-difference-between-Dynamic-loading-and-dynamic-linking

翻译内容如下：

动态装入(Dynamic loading) 指的是当一个进程启动后，将一个可执行的文件（原文是executable，我理解为磁盘上的文件 或者驻留在内存中的例程）或库映射到（或者不常发生的复制）到进程内存空间。动态链接 (dynamic linking)指的是在编译（汇编）之后，分解字符（resolving symbols）——把名字和地址或者偏移量联系起来。这两者难以区分的原因是，大约在进程启动后，编译（汇编）之后这两个过程，通常对二者的微妙区别不加区分地一起完成。大概最清晰的方式来解释这二者的区别就是分别展示二者的各种组合在实践中意味着什么。

动态装入，静态链接。

可执行的文件拥有一个在编译时生成的 地址/偏移量表，但是实际的代码/数据在进程刚启动时没有装到内存中。这并不是大多数现在的操作系统的处理方式，但是它可能描述了一些老式的overlay systems.如果现在的嵌入式系统也使用这种方式，我一点也不感觉到奇怪。无论是哪种情况，其目的都是给予程序员内存控制的自由同时避免运行时的链接花费。

静态装入，动态链接

这通常是在编译时确定动态库的工作方式。可执行文件包含动态/共享库的引用，但是字符表（symbol table）没有或者不完整。装入和链接都在进程启动时进行，被认为是“动态的”链接但不是“动态的”装入。

动态装入，动态链接

这是你调用dlopen或其他系统里的等价调用的时候发生的事情。object(.obj)文件在程序的控制下动态装入（也就是开始之后），包括调用程序和库里的字符都根据那个时刻进程的可能独一无二的内存布局进行解析（把名字和地址/偏移量联系起来）.

静态装入，静态链接

所有的东西都在编译时解析完成。进程开始的时候所有东西都立即加载到内存中，不需要其他的解析（链接linking）。概括地说，加载发生自单个文件是不必要的，但是我认为实际的格式或者实现并不能够在不使用动态链接的情况下实现多文件的装入。

原文内容如下

Dynamic loading refers to mapping (or less often copying) an executable or library into a process's memory after is has started.  Dynamic linking refers to resolving symbols - associating their names with addresses or offsets - after compile time.  The reason it's hard to make a distinction is that the two are often done together without recognizing the subtle distinctions around the parts I put in bold.  Perhaps the clearest way to explain is to go through what the different combinations would mean in practice.

• Dynamic loading, static linking.  The executable has an address/offset table generated at compile time, but the actual code/data aren't loaded into memory at process start.  This is not the way things tend to work in most systems nowadays, but it would describe some old-fashioned overlay systems.  I'd also be utterly unsurprised if some current embedded systems work this way too.  In either case, the goal is to give the programmer control over memory use while also avoiding the overhead of linking at runtime.
• Static loading, dynamic linking.  This is how dynamic libraries specified at compile time usually work.  The executable contains a reference to the dynamic/shared library, but the symbol table is missing or incomplete.  Both loading and linking occur at process start, which is considered "dynamic" for linking but not for loading.
• Dynamic loading, dynamic linking.  This is what happens when you calldlopen or its equivalent on other systems.  The object file is loaded dynamically under program control (i.e. after start), and symbols both in the calling program and in the library are resolved based on the process's possibly-unique memory layout at that time.
  
• Static loading, static linking.  Everything is resolved at compile time.  At process start everything is loaded into memory immediately and no extra resolution (linking) is necessary.  In the abstract it's not necessary for the loading to occur from a single file, but I don't think the actual formats or implementations (at least those I'm familiar with) can do multi-file loading without dynamic linking.

By default, programs are linked so that a reference to a symbol imported from a shared object is bound to that definition at load time.

This is true even if the program, or another shared object required by the program, defines the same symbol.

run time linker

A shared object that allows symbols to be rebound for appropriately linked programs

You include the run time linker in a program by linking the program with the -brtl option. This option has the following effects:

• A reference to the run time linker is added to your program. When program execution begins, the startup code (/lib/crt0.o) will call the run time linker before the main function is called.
• All input files that are shared objects are listed as dependents of your program in your program's loader section. The shared objects are listed in the same order as they were specified on the command line. This causes the system loader to loadall these shared objects so that the run time linker can use their definitions. If the -brtloption is not used, a shared object that is not referenced by the program is not listed, even if it provides definitions that might be needed by another shared object used by the program.
• A shared object contained in an archive is only listed if the archive specifies automatic loading for the shared object member. You specify automatic loading for an archive member foo.o by creating a file with the following lines:

  # autoload #! (foo.o)

  and adding the file as a member to the archive.
• In dynamic mode, input files specified with the -l flag may end in .so, as well as in .a. That is, a reference to -lfoois satisfied by the first libfoo.so or libfoo.a found in any of the directories being searched. Dynamic mode is in effect by default unless the -bstatic option is used.

The run time linker mimics the behavior of the ld command when static linking is used, except that only exported symbols can be used to resolve symbols. Even when run time linking is used, the system loader must be able to load and resolve all symbol references in the main program and any module it depends on. Therefore, if a definition is removed from a module, and the main program has a reference to this definition, the program will not execute, even if another definition for the symbol exists in another module.

The run time linker can rebind all references to symbols imported from another module. A reference to a symbol defined in the same module as the reference can only be rebound if the module was built with run time linking enabled for that symbol.

Shared modules shipped with AIX® 4.2 or later have run time linking enabled for most exported variables. run time linking for functions is only enabled for functions called through a function pointer. For example, as shipped, calls to the malloc subroutine within shared object shr.o in /lib/libc.a cannot be rebound, even if a definition of malloc exists in the main program or another shared module. You can link most shipped shared modules to enable run time linking for functions as well as variables by running the rtl_enable command.

Operation of the run time linker

The main program is loaded and resolved by the system loader in the usual way. If the executable program cannot be loaded for any reason, the exec() subroutine fails and the run time linker is not invoked at all. If the main program loads successfully, control passes to the run time linker, which rebinds symbols as described below. When the run time linker completes, initialization routines are called, if appropriate, and then the main function is called.

The run time linker processes modules in breadth-first search order, starting with the main executable and continuing with the direct dependents of the main executable, according to the order of dependent modules listed in each module's loader section. This order is also used when searching for the defining instance of a symbol. The "defining instance" of a symbol is usually the first instance of a symbol, but there are two exceptions. If the first instance of a symbol is an unresolved, deferred import, no defining instance exists. If the first instance is a BSS symbol (that is, with type XTY_CM, indicating an uninitialized variable), and there is another instance of the symbol that is neither a BSS symbol nor an unresolved, deferred import, the first such instance of the symbol is the defining instance.

The loader section of each module lists imported symbols, which are usually defined in another specified module, and exported symbols, which are usually defined in the module itself. A symbol that is imported and exported is called a "passed-through'' import. Such a symbol appears to be defined in one module, although it is actually defined in another module.

Symbols can also be marked as "deferred imports." References to deferred import symbols are never rebound by the run time linker. Resolution of these symbols must be performed by the system loader, either by calling loadbind() or by loading a new module explicitly with load() or dlopen().

References to imported symbols (other than deferred imports) can always be rebound. The system loader will have already resolved most imports. References to each imported symbol are rebound to the symbol's defining instance. If no defining instance exists, an error message will be printed to standard error. In addition, if the typechecking hash string of an imported symbol does not match the hash string of the defining symbol, an error message is printed.

References to exported symbols are also rebound to their defining instances, as long as the references appear in the relocation table of the loader section. (Passed-through imports are processed along with other imports, as described above.) Depending on how the module was linked, some references to exported symbols are bound at link time and cannot be rebound. Since exported symbols are defined in the exporting module, a defining instance of the symbol will always exist, unless the first instance is a deferred import, so errors are unlikely, but still possible, when rebinding exported symbols. As with imports, errors are printed if the typechecking hash strings do not match when a symbol is rebound.

Whenever a symbol is rebound, a dependency is added from the module using the symbol to the module defining the symbol. This dependency prevents modules from being removed from the address space prematurely. This is important when a module loaded by the dlopen subroutine defines a symbol that is still being used when an attempt is made to unload the module with the dlclose subroutine.

The loader section symbol table does not contain any information about the alignment or length of symbols. Thus, no errors are detected when symbols are rebound to instances that are too short or improperly aligned. Execution errors may occur in this case.

Once all modules have been processed, the run time linker calls the exit subroutine if any run time linking errors occurred, passing an exit code of 144 (0x90). Otherwise, execution continues by calling initialization routines ormain().

Creating a shared object with run time linking enabled

To create a shared object enabled for run time linking, you link with the -G flag. When this flag is used, the following actions take place:

1. Exported symbols are given the nosymbolic attribute, so that all references to the symbols can be rebound by the run time linker.
2. Undefined symbols are permitted (see the -berok option). Such symbols are marked as being imported from the symbolic module name "..". Symbols imported from ".." must be resolved by the run time linker before they can be used because the system loader will not resolve these symbols.
3. The output file is given a module type of SRE, as if the -bM:SRE option had been specified.
4. All shared objects listed on the command line are listed as dependents of the output module, in the same manner as described when linking a program with the -brtl option.
5. Shared objects in archives are listed if they have the autoload attribute.

Using the -berok option, implied by the -G flag, can mask errors that could be detected at link time. If you intend to define all referenced symbols when linking a module, you should use the -bernotok option after the -G flag. This causes errors to be reported for undefined symbols.

xlc -o myprogram main.c -Ldirectory  -ltest

xlc -brtl -o myprogram main.c -Ldirectory -ltest

By using the -l option, you instruct the linker to search in the directory specified via the -L option for libtest.so; if it is not found, the linker searches for libtest.a.
先找静态库，再找动态库。如果找不到so，则找a

 For additional linkage options, including options that modify the default behavior, see the AIX® ld documentation (http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds3/ld.htm).