链接详解

在上一节我们把两个程序文件放在一起编译链接，main.c用到的函数push、pop和is_empty由stack.c提供，其实有一点小问题，我们用-Wall选项编译main.c可以看到：

$ gcc -c main.c -Wall
main.c: In function ‘main’:
main.c:8: warning: implicit declaration of function ‘push’
main.c:12: warning: implicit declaration of function ‘is_empty’
main.c:13: warning: implicit declaration of function ‘pop’

这个问题我们在第 2 节 “自定义函数”讨论过，由于编译器在处理函数调用代码时没有找到函数原型，只好根据函数调用代码做隐式声明，把这三个函数声明为：

int push(char);
int pop(void);
int is_empty(void);

现在你应该比学第 2 节 “自定义函数”的时候更容易理解这条规则了。为什么编译器在处理函数调用代码时需要有函数原型？因为必须知道参数的类型和个数以及返回值的类型才知道生成什么样的指令。为什么隐式声明靠不住呢？因为隐式声明是从函数调用代码推导而来的，而事实上函数定义的形参类型可能跟函数调用代码传的实参类型并不一致，如果函数定义带有可变参数（例如printf），那么从函数调用代码也看不出来这个函数带有可变参数，另外，从函数调用代码也看不出来返回值应该是什么类型，所以隐式声明只能规定返回值都是int型的。既然隐式声明靠不住，那编译器为什么不自己去找函数定义，而非要让我们在调用之前写函数原型呢？因为编译器往往不知道去哪里找函数定义，像上面的例子，我让编译器编译main.c，而这几个函数的定义却在stack.c里，编译器又怎么会知道呢？所以编译器只能通过隐式声明来猜测函数原型，这种猜测往往会出错，但在比较简单的情况下还算可用，比如上一节的例子这么编译过去了也能得到正确结果。

现在我们在main.c中声明这几个函数的原型：

/* main.c */
#include <stdio.h>

extern void push(char);
extern char pop(void);
extern int is_empty(void);

int main(void)
{
	push('a');
	push('b');
	push('c');
	
	while(!is_empty())
		putchar(pop());
	putchar('\n');

	return 0;
}

这样编译器就不会报警告了。在这里extern关键字表示这个标识符具有External Linkage。External Linkage的定义在上一章讲过，但现在应该更容易理解了，push这个标识符具有External Linkage指的是：如果把main.c和stack.c链接在一起，如果push在main.c和stack.c中都有声明（在stack.c中的声明同时也是定义），那么这些声明指的是同一个函数，链接之后是同一个GLOBAL符号，代表同一个地址。函数声明中的extern也可以省略不写，不写extern的函数声明也表示这个函数具有External Linkage。

如果用static关键字修饰一个函数声明，则表示该标识符具有Internal Linkage，例如有以下两个程序文件：

/* foo.c */
static void foo(void) {}

/* main.c */
void foo(void);
int main(void) { foo(); return 0; }

编译链接在一起会出错：

$ gcc foo.c main.c
/tmp/ccRC2Yjn.o: In function `main':
main.c:(.text+0x12): undefined reference to `foo'
collect2: ld returned 1 exit status

虽然在foo.c中定义了函数foo，但这个函数只具有Internal Linkage，只有在foo.c中多次声明才表示同一个函数，而在main.c中声明就不表示它了。如果把foo.c编译成目标文件，函数名foo在其中是一个LOCAL的符号，不参与链接过程，所以在链接时，main.c中用到一个External Linkage的foo函数，链接器却找不到它的定义在哪儿，无法确定它的地址，也就无法做符号解析，只好报错。凡是被多次声明的变量或函数，必须有且只有一个声明是定义，如果有多个定义，或者一个定义都没有，链接器就无法完成链接。

以上讲了用static和extern修饰函数声明的情况。现在来看用它们修饰变量声明的情况。仍然用stack.c和main.c的例子，如果我想在main.c中直接访问stack.c中定义的变量top，则可以用extern声明它：

/* main.c */
#include <stdio.h>

void push(char);
char pop(void);
int is_empty(void);
extern int top;

int main(void)
{
	push('a');
	push('b');
	push('c');
	printf("%d\n", top);
	
	while(!is_empty())
		putchar(pop());
	putchar('\n');
	printf("%d\n", top);

	return 0;
}

变量top具有External Linkage，它的存储空间是在stack.c中分配的，所以main.c中的变量声明extern int top;不是变量定义，因为它不分配存储空间。以上函数和变量声明也可以写在main函数体里面，使所声明的标识符具有块作用域：

int main(void)
{
	void push(char);
	char pop(void);
	int is_empty(void);
	extern int top;

	push('a');
	push('b');
	push('c');
	printf("%d\n", top);
	
	while(!is_empty())
		putchar(pop());
	putchar('\n');
	printf("%d\n", top);

	return 0;
}

注意，变量声明和函数声明有一点不同，函数声明的extern可写可不写，而变量声明如果不写extern意思就完全变了，如果上面的例子不写extern就表示在main函数中定义一个局部变量top。另外要注意，stack.c中的定义是int top = -1;，而main.c中的声明不能加Initializer，如果上面的例子写成extern int top = -1;则编译器会报错。

在main.c中可以通过变量声明来访问stack.c中的变量top，但是从实现stack.c这个模块的角度来看，top这个变量是不希望被外界访问到的，变量top和stack都属于这个模块的内部状态，外界应该只允许通过push和pop函数来改变模块的内部状态，这样才能保证堆栈的LIFO特性，如果外界可以随机访问stack或者随便修改top，那么堆栈的状态就乱了。那怎么才能阻止外界访问top和stack呢？答案就是用static关键字把它们声明为Internal Linkage的：

/* stack.c */
static char stack[512];
static int top = -1;

void push(char c)
{
	stack[++top] = c;
}

char pop(void)
{
	return stack[top--];
}

int is_empty(void)
{
	return top == -1;
}

这样，即使在main.c中用extern声明也访问不到stack.c的变量top和stack。从而保护了stack.c模块的内部状态，这也是一种封装（Encapsulation）的思想。

用static关键字声明具有Internal Linkage的函数也是出于这个目的。在一个模块中，有些函数是提供给外界使用的，也称为导出（Export）给外界使用，这些函数声明为External Linkage的。有些函数只在模块内部使用而不希望被外界访问到，则声明为Internal Linkage的。

我们继续前面关于stack.c和main.c的讨论。stack.c这个模块封装了top和stack两个变量，导出了push、pop、is_empty三个函数接口，已经设计得比较完善了。但是使用这个模块的每个程序文件都要写三个函数声明也是很麻烦的，假设又有一个foo.c也使用这个模块，main.c和foo.c中各自要写三个函数声明。重复的代码总是应该尽量避免的，以前我们通过各种办法把重复的代码提取出来，比如在第 2 节 “数组应用实例：统计随机数”讲过用宏定义避免硬编码的问题，这次有什么办法呢？答案就是可以自己写一个头文件stack.h：

/* stack.h */
#ifndef STACK_H
#define STACK_H
extern void push(char);
extern char pop(void);
extern int is_empty(void);
#endif

这样在main.c中只需包含这个头文件就可以了，而不需要写三个函数声明：

/* main.c */
#include <stdio.h>
#include "stack.h"

int main(void)
{
	push('a');
	push('b');
	push('c');
	
	while(!is_empty())
		putchar(pop());
	putchar('\n');

	return 0;
}

首先说为什么#include <stdio.h>用角括号，而#include "stack.h"用引号。对于用角括号包含的头文件，gcc首先查找-I选项指定的目录，然后查找系统的头文件目录（通常是/usr/include，在我的系统上还包括/usr/lib/gcc/i486-linux-gnu/4.3.2/include）；而对于用引号包含的头文件，gcc首先查找包含头文件的.c文件所在的目录，然后查找-I选项指定的目录，然后查找系统的头文件目录。

假如三个代码文件都放在当前目录下：

$ tree
.
|-- main.c
|-- stack.c
`-- stack.h

0 directories, 3 files

则可以用gcc -c main.c编译，gcc会自动在main.c所在的目录中找到stack.h。假如把stack.h移到一个子目录下：

$ tree
.
|-- main.c
`-- stack
    |-- stack.c
    `-- stack.h

1 directory, 3 files

则需要用gcc -c main.c -Istack编译。用-I选项告诉gcc头文件要到子目录stack里找。

在#include预处理指示中可以使用相对路径，例如把上面的代码改成#include "stack/stack.h"，那么编译时就不需要加-Istack选项了，因为gcc会自动在main.c所在的目录中查找，而头文件相对于main.c所在目录的相对路径正是stack/stack.h。

在stack.h中我们又看到两个新的预处理指示#ifndef STACK_H和#endif，意思是说，如果STACK_H这个宏没有定义过，那么从#ifndef到#endif之间的代码就包含在预处理的输出结果中，否则这一段代码就不出现在预处理的输出结果中。stack.h这个头文件的内容整个被#ifndef和#endif括起来了，如果在包含这个头文件时STACK_H这个宏已经定义过了，则相当于这个头文件里什么都没有，包含了一个空文件。这有什么用呢？假如main.c包含了两次stack.h：

...
#include "stack.h"
#include "stack.h"

int main(void)
{
...

则第一次包含stack.h时并没有定义STACK_H这个宏，因此头文件的内容包含在预处理的输出结果中：

...
#define STACK_H
extern void push(char);
extern char pop(void);
extern int is_empty(void);
#include "stack.h"

int main(void)
{
...

其中已经定义了STACK_H这个宏，因此第二次再包含stack.h就相当于包含了一个空文件，这就避免了头文件的内容被重复包含。这种保护头文件的写法称为Header Guard，以后我们每写一个头文件都要加上Header Guard，宏定义名就用头文件名的大写形式，这是规范的做法。

那为什么需要防止重复包含呢？谁会把一个头文件包含两次呢？像上面那么明显的错误没人会犯，但有时候重复包含的错误并不是那么明显的。比如：

#include "stack.h"
#include "foo.h"

然而foo.h里又包含了bar.h，bar.h里又包含了stack.h。在规模较大的项目中头文件包含头文件的情况很常见，经常会包含四五层，这时候重复包含的问题就很难发现了。比如在我的系统头文件目录/usr/include中，errno.h包含了bits/errno.h，后者又包含了linux/errno.h，后者又包含了asm/errno.h，后者又包含了asm-generic/errno.h。

另外一个问题是，就算我是重复包含了头文件，那有什么危害么？像上面的三个函数声明，在程序中声明两次也没有问题，对于具有External Linkage的函数，声明任意多次也都代表同一个函数。重复包含头文件有以下问题：

还有一个问题，既然要#include头文件，那我不如直接在main.c中#include "stack.c"得了。这样把stack.c和main.c合并为同一个程序文件，相当于又回到最初的例 12.1 “用堆栈实现倒序打印”了。当然这样也能编译通过，但是在一个规模较大的项目中不能这么做，假如又有一个foo.c也要使用stack.c这个模块怎么办呢？如果在foo.c里面也#include "stack.c"，就相当于push、pop、is_empty这三个函数在main.c和foo.c中都有定义，那么main.c和foo.c就不能链接在一起了。如果采用包含头文件的办法，那么这三个函数只在stack.c中定义了一次，最后可以把main.c、stack.c、foo.c链接在一起。如下图所示：

同样道理，头文件中的变量和函数声明一定不能是定义。如果头文件中出现变量或函数定义，这个头文件又被多个.c文件包含，那么这些.c文件就不能链接在一起了。

以上两节关于定义和声明只介绍了最基本的规则，在写代码时掌握这些基本规则就够用了，但其实C语言关于定义和声明还有很多复杂的规则，在分析错误原因或者维护规模较大的项目时需要了解这些规则。本节的两个表格出自[Standard C]。

首先看关于函数声明的规则。

以前我们说“extern关键字表示这个标识符具有External Linkage”其实是不准确的，准确地说应该是Previous Linkage。Previous Linkage的定义是：这次声明的标识符具有什么样的Linkage取决于前一次声明，这前一次声明具有相同的标识符名，而且必须是文件作用域的声明，如果在程序文件中找不到前一次声明（这次声明是第一次声明），那么这个标识符具有External Linkage。例如在一个程序文件中在文件作用域两次声明同一个函数：

static int f(void); /* internal linkage */
extern int f(void); /* previous linkage */

则这里的extern修饰的标识符具有Interanl Linkage而不是External Linkage。从上表的前两行可以总结出我们先前所说的规则“函数声明加不加extern关键字都一样”。上表也说明了在文件作用域允许定义函数，在块作用域不允许定义函数，或者说函数定义不能嵌套。另外，在块作用域中不允许用static关键字声明函数。

关于变量声明的规则要复杂一些：

上表的每个单元格里分成四行，分别描述变量的链接属性、生存期，以及这种变量如何初始化，是否算变量定义。链接属性有External Linkage、Internal Linkage、No Linkage和Previous Linkage四种情况，生存期有Static Duration和Automatic Duration两种情况，请参考本章和上一章的定义。初始化有Static Initializer和Dynamic Initializer两种情况，前者表示Initializer中只能使用常量表达式，表达式的值必须在编译时就能确定，后者表示Initializer中可以使用任意的右值表达式，表达式的值可以在运行时计算。是否算变量定义有三种情况，Definition（算变量定义）、Not a Definition（不算变量定义）和Tentative Definition（暂定的变量定义）。什么叫“暂定的变量定义”呢？一个变量声明具有文件作用域，没有Storage Class关键字修饰，或者用static关键字修饰，那么如果它有Initializer则编译器认为它就是一个变量定义，如果它没有Initializer则编译器暂定它是变量定义，如果程序文件中有这个变量的明确定义就用明确定义，如果程序文件没有这个变量的明确定义，就用这个暂定的变量定义^[32]，这种情况下变量以0初始化。在[C99]中有一个例子：

int i1 = 1; // definition, external linkage
static int i2 = 2; // definition, internal linkage
extern int i3 = 3; // definition, external linkage
int i4; // tentative definition, external linkage
static int i5; // tentative definition, internal linkage
int i1; // valid tentative definition, refers to previous
int i2; // 6.2.2 renders undefined, linkage disagreement
int i3; // valid tentative definition, refers to previous
int i4; // valid tentative definition, refers to previous
int i5; // 6.2.2 renders undefined, linkage disagreement
extern int i1; // refers to previous, whose linkage is external
extern int i2; // refers to previous, whose linkage is internal
extern int i3; // refers to previous, whose linkage is external
extern int i4; // refers to previous, whose linkage is external
extern int i5; // refers to previous, whose linkage is internal

变量i2和i5第一次声明为Internal Linkage，第二次又声明为External Linkage，这是不允许的，编译器会报错。注意上表中标有[*]的单元格，对于文件作用域的extern变量声明，C99是允许带Initializer的，并且认为它是一个定义，但是gcc对于这种写法会报警告，为了兼容性应避免这种写法。

组成共享库的目标文件和一般的目标文件有所不同，在编译时要加-fPIC选项，例如：

$ gcc -c -fPIC stack/stack.c stack/push.c stack/pop.c stack/is_empty.c

-f后面跟一些编译选项，PIC是其中一种，表示生成位置无关代码（Position Independent Code）。那么用-fPIC生成的目标文件和一般的目标文件有什么不同呢？下面分析这个问题。

我们知道一般的目标文件称为Relocatable，在链接时可以把目标文件中各段的地址做重定位，重定位时需要修改指令。我们先不加-fPIC选项编译生成目标文件：

$ gcc -c -g stack/stack.c stack/push.c stack/pop.c stack/is_empty.c

由于接下来要用objdump -dS把反汇编指令和源代码穿插起来分析，所以用-g选项加调试信息。注意，加调试信息必须在编译每个目标文件时用-g选项，而不能只在最后编译生成可执行文件时用-g选项。反汇编查看push.o：

$ objdump -dS push.o 

push.o:     file format elf32-i386


Disassembly of section .text:

00000000 <push>:
/* push.c */
extern char stack[512];
extern int top;

void push(char c)
{
   0:	55                   	push   %ebp
   1:	89 e5                	mov    %esp,%ebp
   3:	83 ec 04             	sub    $0x4,%esp
   6:	8b 45 08             	mov    0x8(%ebp),%eax
   9:	88 45 fc             	mov    %al,-0x4(%ebp)
	stack[++top] = c;
   c:	a1 00 00 00 00       	mov    0x0,%eax
  11:	83 c0 01             	add    $0x1,%eax
  14:	a3 00 00 00 00       	mov    %eax,0x0
  19:	8b 15 00 00 00 00    	mov    0x0,%edx
  1f:	0f b6 45 fc          	movzbl -0x4(%ebp),%eax
  23:	88 82 00 00 00 00    	mov    %al,0x0(%edx)
}
  29:	c9                   	leave  
  2a:	c3                   	ret

指令中凡是用到stack和top的地址都用0x0表示，准备在重定位时修改。再看readelf输出的.rel.text段的信息：

Relocation section '.rel.text' at offset 0x848 contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0000000d  00001001 R_386_32          00000000   top
00000015  00001001 R_386_32          00000000   top
0000001b  00001001 R_386_32          00000000   top
00000025  00001101 R_386_32          00000000   stack

标出了指令中有四处需要在重定位时修改。下面编译链接成可执行文件之后再做反汇编分析：

$ gcc -g main.c stack.o push.o pop.o is_empty.o -Istack -o main
$ objdump -dS main
...
080483c0 <push>:
/* push.c */
extern char stack[512];
extern int top;

void push(char c)
{
 80483c0:       55                      push   %ebp
 80483c1:       89 e5                   mov    %esp,%ebp
 80483c3:       83 ec 04                sub    $0x4,%esp
 80483c6:       8b 45 08                mov    0x8(%ebp),%eax
 80483c9:       88 45 fc                mov    %al,-0x4(%ebp)
        stack[++top] = c;
 80483cc:       a1 10 a0 04 08          mov    0x804a010,%eax
 80483d1:       83 c0 01                add    $0x1,%eax
 80483d4:       a3 10 a0 04 08          mov    %eax,0x804a010
 80483d9:       8b 15 10 a0 04 08       mov    0x804a010,%edx
 80483df:       0f b6 45 fc             movzbl -0x4(%ebp),%eax
 80483e3:       88 82 40 a0 04 08       mov    %al,0x804a040(%edx)
}
 80483e9:       c9                      leave  
 80483ea:       c3                      ret    
 80483eb:       90                      nop    
...

原来指令中的0x0被修改成了0x804a010和0x804a040，这样做了重定位之后，各段的加载地址就定死了，因为在指令中使用了绝对地址。

现在看用-fPIC编译生成的目标文件有什么不同：

$ gcc -c -g -fPIC stack/stack.c stack/push.c stack/pop.c stack/is_empty.c
$ objdump -dS push.o

push.o:     file format elf32-i386


Disassembly of section .text:

00000000 <push>:
/* push.c */
extern char stack[512];
extern int top;

void push(char c)
{
   0:	55                   	push   %ebp
   1:	89 e5                	mov    %esp,%ebp
   3:	53                   	push   %ebx
   4:	83 ec 04             	sub    $0x4,%esp
   7:	e8 fc ff ff ff       	call   8 <push+0x8>
   c:	81 c3 02 00 00 00    	add    $0x2,%ebx
  12:	8b 45 08             	mov    0x8(%ebp),%eax
  15:	88 45 f8             	mov    %al,-0x8(%ebp)
	stack[++top] = c;
  18:	8b 83 00 00 00 00    	mov    0x0(%ebx),%eax
  1e:	8b 00                	mov    (%eax),%eax
  20:	8d 50 01             	lea    0x1(%eax),%edx
  23:	8b 83 00 00 00 00    	mov    0x0(%ebx),%eax
  29:	89 10                	mov    %edx,(%eax)
  2b:	8b 83 00 00 00 00    	mov    0x0(%ebx),%eax
  31:	8b 08                	mov    (%eax),%ecx
  33:	8b 93 00 00 00 00    	mov    0x0(%ebx),%edx
  39:	0f b6 45 f8          	movzbl -0x8(%ebp),%eax
  3d:	88 04 0a             	mov    %al,(%edx,%ecx,1)
}
  40:	83 c4 04             	add    $0x4,%esp
  43:	5b                   	pop    %ebx
  44:	5d                   	pop    %ebp
  45:	c3                   	ret    

Disassembly of section .text.__i686.get_pc_thunk.bx:

00000000 <__i686.get_pc_thunk.bx>:
   0:	8b 1c 24             	mov    (%esp),%ebx
   3:	c3                   	ret

指令中用到的stack和top的地址不再以0x0表示，而是以0x0(%ebx)表示，但其中还是留有0x0准备做进一步修改。再看readelf输出的.rel.text段：

Relocation section '.rel.text' at offset 0x94c contains 6 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000008  00001202 R_386_PC32        00000000   __i686.get_pc_thunk.bx
0000000e  0000130a R_386_GOTPC       00000000   _GLOBAL_OFFSET_TABLE_
0000001a  00001403 R_386_GOT32       00000000   top
00000025  00001403 R_386_GOT32       00000000   top
0000002d  00001403 R_386_GOT32       00000000   top
00000035  00001503 R_386_GOT32       00000000   stack

top和stack对应的记录类型不再是R_386_32了，而是R_386_GOT32，有什么区别呢？我们先编译生成共享库再做反汇编分析：

$ gcc -shared -o libstack.so stack.o push.o pop.o is_empty.o
$ objdump -dS libstack.so
...
0000047c <push>:
/* push.c */
extern char stack[512];
extern int top;

void push(char c)
{
 47c:	55                   	push   %ebp
 47d:	89 e5                	mov    %esp,%ebp
 47f:	53                   	push   %ebx
 480:	83 ec 04             	sub    $0x4,%esp
 483:	e8 ef ff ff ff       	call   477 <__i686.get_pc_thunk.bx>
 488:	81 c3 6c 1b 00 00    	add    $0x1b6c,%ebx
 48e:	8b 45 08             	mov    0x8(%ebp),%eax
 491:	88 45 f8             	mov    %al,-0x8(%ebp)
	stack[++top] = c;
 494:	8b 83 f4 ff ff ff    	mov    -0xc(%ebx),%eax
 49a:	8b 00                	mov    (%eax),%eax
 49c:	8d 50 01             	lea    0x1(%eax),%edx
 49f:	8b 83 f4 ff ff ff    	mov    -0xc(%ebx),%eax
 4a5:	89 10                	mov    %edx,(%eax)
 4a7:	8b 83 f4 ff ff ff    	mov    -0xc(%ebx),%eax
 4ad:	8b 08                	mov    (%eax),%ecx
 4af:	8b 93 f8 ff ff ff    	mov    -0x8(%ebx),%edx
 4b5:	0f b6 45 f8          	movzbl -0x8(%ebp),%eax
 4b9:	88 04 0a             	mov    %al,(%edx,%ecx,1)
}
 4bc:	83 c4 04             	add    $0x4,%esp
 4bf:	5b                   	pop    %ebx
 4c0:	5d                   	pop    %ebp
 4c1:	c3                   	ret    
 4c2:	90                   	nop    
 4c3:	90                   	nop    
...

和先前的结果不同，指令中的0x0(%ebx)被修改成-0xc(%ebx)和-0x8(%ebx)，而不是修改成绝对地址。所以共享库各段的加载地址并没有定死，可以加载到任意位置，因为指令中没有使用绝对地址，因此称为位置无关代码。另外，注意这几条指令：

 494:	8b 83 f4 ff ff ff    	mov    -0xc(%ebx),%eax
 49a:	8b 00                	mov    (%eax),%eax
 49c:	8d 50 01             	lea    0x1(%eax),%edx

和先前的指令对比一下：

 80483cc:       a1 10 a0 04 08          mov    0x804a010,%eax
 80483d1:       83 c0 01                add    $0x1,%eax

可以发现，-0xc(%ebx)这个地址并不是变量top的地址，这个地址的内存单元中又保存了另外一个地址，这另外一个地址才是变量top的地址，所以mov -0xc(%ebx),%eax是把变量top的地址传给eax，而mov (%eax),%eax才是从top的地址中取出top的值传给eax。lea 0x1(%eax),%edx是把top的值加1存到edx中，如下图所示：

top和stack的绝对地址保存在一个地址表中，而指令通过地址表做间接寻址，因此避免了将绝对地址写死在指令中，这也是一种避免硬编码的策略。

现在把main.c和共享库编译链接在一起，然后运行：

$ gcc main.c -g -L. -lstack -Istack -o main
$ ./main 
./main: error while loading shared libraries: libstack.so: cannot open shared object file: No such file or directory

结果出乎意料，编译的时候没问题，由于指定了-L.选项，编译器可以在当前目录下找到libstack.so，而运行时却说找不到libstack.so。那么运行时在哪些路径下找共享库呢？我们先用ldd命令查看可执行文件依赖于哪些共享库：

$ ldd main
	linux-gate.so.1 =>  (0xb7f5c000)
	libstack.so => not found
	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dcf000)
	/lib/ld-linux.so.2 (0xb7f42000)

ldd模拟运行一遍main，在运行过程中做动态链接，从而得知这个可执行文件依赖于哪些共享库，每个共享库都在什么路径下，加载到进程地址空间的什么地址。/lib/ld-linux.so.2是动态链接器，它的路径是在编译链接时指定的，我们在第 2 节 “main函数和启动例程”讲过gcc在做链接时用-dynamic-linker指定动态链接器的路径，它也像其它共享库一样加载到进程的地址空间中。libc.so.6的路径/lib/tls/i686/cmov/libc.so.6是由动态链接器ld-linux.so.2在做动态链接时搜索到的，而libstack.so的路径没有找到。linux-gate.so.1这个共享库其实并不存在于文件系统中，它是由内核虚拟出来的共享库，所以它没有对应的路径，它负责处理系统调用。总之，共享库的搜索路径由动态链接器决定，从ld.so(8)的Man Page可以查到共享库路径的搜索顺序：

先试试第一种方法，在运行main时通过环境变量LD_LIBRARY_PATH把当前目录添加到共享库的搜索路径：

$ LD_LIBRARY_PATH=. ./main

这种方法只适合在开发中临时用一下，通常LD_LIBRARY_PATH是不推荐使用的，尽量不要设置这个环境变量，理由可以参考Why LD_LIBRARY_PATH is bad（http://www.visi.com/~barr/ldpath.html）。

再试试第二种方法，这是最常用的方法。把libstack.so所在目录的绝对路径（比如/home/akaedu/somedir）添加到/etc/ld.so.conf中（该文件中每个路径占一行），然后运行ldconfig：

$ sudo ldconfig -v
...
/home/akaedu/somedir:
        libstack.so -> libstack.so
/lib:
        libe2p.so.2 -> libe2p.so.2.3
        libncursesw.so.5 -> libncursesw.so.5.6
...
/usr/lib:
        libkdeinit_klauncher.so -> libkdeinit_klauncher.so
        libv4l2.so.0 -> libv4l2.so.0
...
/usr/lib64:
/lib/tls: (hwcap: 0x8000000000000000)
/usr/lib/sse2: (hwcap: 0x0000000004000000)
...
/usr/lib/tls: (hwcap: 0x8000000000000000)
...
/usr/lib/i686: (hwcap: 0x0008000000000000)
/usr/lib/i586: (hwcap: 0x0004000000000000)
...
/usr/lib/i486: (hwcap: 0x0002000000000000)
...
/lib/tls/i686: (hwcap: 0x8008000000000000)
/usr/lib/i686/cmov: (hwcap: 0x0008000000008000)
...
/lib/tls/i686/cmov: (hwcap: 0x8008000000008000)

ldconfig命令除了处理/etc/ld.so.conf中配置的目录之外，还处理一些默认目录，如/lib、/usr/lib等，处理之后生成/etc/ld.so.cache缓存文件，动态链接器就从这个缓存中搜索共享库。hwcap是x86平台的Linux特有的一种机制，系统检测到当前平台是i686而不是i586或i486，所以在运行程序时使用i686的库，这样可以更好地发挥平台的性能，也可以利用一些新的指令，所以上面ldd命令的输出结果显示动态链接器搜索到的libc是/lib/tls/i686/cmov/libc.so.6，而不是/lib/libc.so.6。现在再用ldd命令查看，libstack.so就能找到了：

$ ldd main
	linux-gate.so.1 =>  (0xb809c000)
	libstack.so => /home/akaedu/somedir/libstack.so (0xb806a000)
	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7f0c000)
	/lib/ld-linux.so.2 (0xb8082000)

第三种方法就是把libstack.so拷到/usr/lib或/lib目录，这样可以确保动态链接器能找到这个共享库。

其实还有第四种方法，在编译可执行文件main的时候就把libstack.so的路径写死在可执行文件中：

$ gcc main.c -g -L. -lstack -Istack -o main -Wl,-rpath,/home/akaedu/somedir

-Wl,-rpath,/home/akaedu/somedir表示-rpath /home/akaedu/somedir是由gcc传递给链接器的选项。可以看到readelf的结果多了一条rpath记录：

$ readelf -a main
...
Dynamic section at offset 0xf10 contains 23 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libstack.so]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000f (RPATH)                      Library rpath: [/home/akaedu/somedir]
...

还可以看出，可执行文件运行时需要哪些共享库也都记录在.dynamic段中。当然rpath这种办法也是不推荐的，把共享库的路径定死了，失去了灵活性。

本节研究一下在main.c中调用共享库的函数push是如何实现的。首先反汇编看一下main的指令：

$ objdump -dS main
...
Disassembly of section .plt:

080483a8 <__gmon_start__@plt-0x10>:
 80483a8:	ff 35 f8 9f 04 08    	pushl  0x8049ff8
 80483ae:	ff 25 fc 9f 04 08    	jmp    *0x8049ffc
 80483b4:	00 00                	add    %al,(%eax)
...
080483d8 <push@plt>:
 80483d8:	ff 25 08 a0 04 08    	jmp    *0x804a008
 80483de:	68 10 00 00 00       	push   $0x10
 80483e3:	e9 c0 ff ff ff       	jmp    80483a8 <_init+0x30>

Disassembly of section .text:
...
080484a4 <main>:
/* main.c */
#include <stdio.h>
#include "stack.h"

int main(void)
{
 80484a4:	8d 4c 24 04          	lea    0x4(%esp),%ecx
 80484a8:	83 e4 f0             	and    $0xfffffff0,%esp
 80484ab:	ff 71 fc             	pushl  -0x4(%ecx)
 80484ae:	55                   	push   %ebp
 80484af:	89 e5                	mov    %esp,%ebp
 80484b1:	51                   	push   %ecx
 80484b2:	83 ec 04             	sub    $0x4,%esp
	push('a');
 80484b5:	c7 04 24 61 00 00 00 	movl   $0x61,(%esp)
 80484bc:	e8 17 ff ff ff       	call   80483d8 <push@plt>
...

和第 3 节 “静态库”链接静态库不同，push函数没有链接到可执行文件中。而且call 80483d8 <push@plt>这条指令调用的也不是push函数的地址。共享库是位置无关代码，在运行时可以加载到任意地址，其加载地址只有在动态链接时才能确定，所以在main函数中不可能直接通过绝对地址调用push函数，也是通过间接寻址来找push函数的。对照着上面的指令，我们用gdb跟踪一下：

$ gdb main
...
(gdb) start
Breakpoint 1 at 0x80484b5: file main.c, line 7.
Starting program: /home/akaedu/somedir/main 
main () at main.c:7
7		push('a');
(gdb) si
0x080484bc	7		push('a');
(gdb) si
0x080483d8 in push@plt ()
Current language:  auto; currently asm

跳转到.plt段中，现在将要执行一条jmp *0x804a008指令，我们看看0x804a008这个地址里存的是什么：

(gdb) x 0x804a008
0x804a008 <_GLOBAL_OFFSET_TABLE_+20>:	0x080483de

原来就是下一条指令push $0x10的地址。继续跟踪下去：

(gdb) si
0x080483de in push@plt ()
(gdb) si
0x080483e3 in push@plt ()
(gdb) si
0x080483a8 in ?? ()
(gdb) si
0x080483ae in ?? ()
(gdb) si
0xb806a080 in ?? () from /lib/ld-linux.so.2

最终进入了动态链接器/lib/ld-linux.so.2，在其中完成动态链接的过程并调用push函数，我们不深入这些细节了，直接用finish命令返回到main函数：

(gdb) finish
Run till exit from #0  0xb806a080 in ?? () from /lib/ld-linux.so.2
main () at main.c:8
8		return 0;
Current language:  auto; currently c

这时再看看0x804a008这个地址里存的是什么：

(gdb) x 0x804a008
0x804a008 <_GLOBAL_OFFSET_TABLE_+20>:	0xb803f47c
(gdb) x 0xb803f47c
0xb803f47c <push>:	0x53e58955

动态链接器已经把push函数的地址存在这里了，所以下次再调用push函数就可以直接从jmp *0x804a008指令跳到它的地址，而不必再进入/lib/ld-linux.so.2做动态链接了。

你可能已经注意到了，系统的共享库通常带有符号链接，例如：

$ ls -l  /lib
...
-rwxr-xr-x  1 root root 1315024 2009-01-09 22:10 libc-2.8.90.so
lrwxrwxrwx  1 root root      14 2008-07-04 05:58 libcap.so.1 -> libcap.so.1.10
-rw-r--r--  1 root root   10316 2007-08-01 03:20 libcap.so.1.10
lrwxrwxrwx  1 root root      14 2008-11-01 08:55 libcap.so.2 -> libcap.so.2.10
-rw-r--r--  1 root root   13792 2008-06-12 21:39 libcap.so.2.10
...
lrwxrwxrwx  1 root root      14 2009-01-13 09:28 libc.so.6 -> libc-2.8.90.so
...
$ ls -l /usr/lib/libc.so
-rw-r--r-- 1 root root 238 2009-01-09 21:59 /usr/lib/libc.so

按照共享库的命名惯例，每个共享库有三个文件名：real name、soname和linker name。真正的库文件（而不是符号链接）的名字是real name，包含完整的共享库版本号。例如上面的libcap.so.1.10、libc-2.8.90.so等。

soname是一个符号链接的名字，只包含共享库的主版本号，主版本号一致即可保证库函数的接口一致，因此应用程序的.dynamic段只记录共享库的soname，只要soname一致，这个共享库就可以用。例如上面的libcap.so.1和libcap.so.2是两个主版本号不同的libcap，有些应用程序依赖于libcap.so.1，有些应用程序依赖于libcap.so.2，但对于依赖libcap.so.1的应用程序来说，真正的库文件不管是libcap.so.1.10还是libcap.so.1.11都可以用，所以使用共享库可以很方便地升级库文件而不需要重新编译应用程序，这是静态库所没有的优点。注意libc的版本编号有一点特殊，libc-2.8.90.so的主版本号是6而不是2或2.8。

linker name仅在编译链接时使用，gcc的-L选项应该指定linker name所在的目录。有的linker name是库文件的一个符号链接，有的linker name是一段链接脚本。例如上面的libc.so就是一个linker name，它是一段链接脚本：

$ cat /usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux.so.2 ) )

下面重新编译我们的libstack，指定它的soname：

$ gcc -shared -Wl,-soname,libstack.so.1 -o libstack.so.1.0 stack.o push.o pop.o is_empty.o

这样编译生成的库文件是libstack.so.1.0，是real name，但这个库文件中记录了它的soname是libstack.so.1：

$ readelf -a libstack.so.1.0
...
Dynamic section at offset 0xf10 contains 22 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [libstack.so.1]
...

如果把libstack.so.1.0所在的目录加入/etc/ld.so.conf中，然后运行ldconfig命令，ldconfig会自动创建一个soname的符号链接：

$ sudo ldconfig
$ ls -l libstack*
lrwxrwxrwx 1 root    root       15 2009-01-21 17:52 libstack.so.1 -> libstack.so.1.0
-rwxr-xr-x 1 akaedu  akaedu  10142 2009-01-21 17:49 libstack.so.1.0

但这样编译链接main.c却会报错：

$ gcc main.c -L. -lstack -Istack -o main
/usr/bin/ld: cannot find -lstack
collect2: ld returned 1 exit status

注意，要做这个实验，你得把先前编译的libstack共享库、静态库都删掉，如果先前拷到/lib或者/usr/lib下了也删掉，只留下libstack.so.1.0和libstack.so.1，这样你会发现编译器不认这两个名字，因为编译器只认linker name。可以先创建一个linker name的符号链接，然后再编译就没问题了：

$ ln -s libstack.so.1.0 libstack.so
$ gcc main.c -L. -lstack -Istack -o main