【Linux】基础IO —— 下（实现动静态库）

🎇Linux：基础IO

---

• 博客主页：一起去看日落吗
• 分享博主的在Linux中学习到的知识和遇到的问题
• 博主的能力有限，出现错误希望大家不吝赐教
• 分享给大家一句我很喜欢的话： 看似不起波澜的日复一日，一定会在某一天让你看见坚持的意义，祝我们都能在鸡零狗碎里找到闪闪的快乐🌿🌞🐾。

---

☁️ ❄️ ⛄️

---

⛄️1. Linux动静态库

❄️ 1.1 认识动静态库

#include

int main()
{
    printf("hello byh\n");
    return 0;
}

1
2
3
4
5
6
7
8

这段代码的运行结果大家一眼就可以看出来了

在Linux下我们可以通过ldd指令来查看一个可执行程序所依赖的库文件

ldd [某可执行程序]  
1

这里的libc.so.6就是当前可执行程序所依赖的库文件，我们通过ls命令查看后发现libc.so.6它其实就是一个软链接。

这就是我们使用的C标准库，它的大小是 2156592 这么些。我们使用的标准IO、字符串操作和整数数学函数所谓的这些的库，也不过是安装在系统中的文件罢了。

这个时候我就有一个问题：那么我们怎么知道这个库是一个动态库还是静态库呢？

上面说了libc.so.6它是一个软链接，而该软链接的源文件就是libc-2.17.so。因此我们可以通过file+文件名来查看一下libc-2.17.so的文件类型

file /lib64/libc-2.17.so
1

可以看到libc-2.17.so它其实是一个动态库

注意：

• 在Linux下，以.so为后缀的文件是动态库，以.a为后缀的文件是静态库
• 在Windows下，以.dll为后缀的文件是动态库，以.lib为后缀的文件是静态库

在Linux下，libbyh.so，我们去掉前缀lib，去掉后缀.so，剩下的就是该动静态库的库名了。

在Linux下，gcc/g++编译器默认采用的是动态链接，若是想采用静态链接的话，我们需要在gcc/g++后面带上一个-static选项即可。

大家在使用gcc/g++命令带这个选项的时候可能会由于当前云服务器上面没有下载静态库而导致出错，因此我们需要先使用下面这两条命令分别下载gcc/g++静态库之后再去进行静态链接，这样的话就不会出错了。

yum install glibc-static
yum install glibc-static libstdc++-static
1
2

我们生成一个静态链接的可执行程序，我们可以看到静态链接生成的可执行程序文件比动态链接生成的可执行程序的文件大小要大很多，将近大了100倍。由于静态链接所生成的可执行程序它不依赖第三方库，因此当我们通过ldd指令去查看静态链接生成的可执行程序所依赖的库文件时就会出现下面这一幕：

当我们用file命令分别查看这个可执行程序的文件类型时，我们可以看到它是静态链接的。

---

❄️ 1.2 动态库

动态库是程序在运行的时候才去链接动态库的代码，多个程序共享使用库的代码。一个与动态库链接的可执行文件仅仅包含它用到的函数入口地址的一个表，而不是外部函数所在目标文件的整个机器码

在可执行文件开始运行以前，外部函数的机器码由操作系统从磁盘上的该动态库中复制到内存中，这个过程称为动态链接

动态库可以在多个程序间共享，所以动态链接使得可执行文件更小，节省了磁盘空间。操作系统采用虚拟内存机制允许物理内存中的一份动态库被要用到该库的所有进程共用，节省了内存和磁盘空间。

优点：

• 使用动态库生成的可执行程序体积比较小，节省资源。当多个可执行程序同时运行时，若是要使用同一个库，库文件会通过进程地址空间进行共享，内存中不会存在重复代码。

缺点：

• 比较依赖第三方库。

---

❄️ 1.3 静态库

静态库是在程序编译链接的时候将库中的代码拷贝到可执行程序里面，生成的可执行程序就不再需要依赖第三方库，同时生成的可执行程序的体积比较大。

优点：

• 使用静态库生成的可执行程序，它不需要依赖于第三方库，即使没有第三方库它也可以独立运行，可移植性高。

缺点：

• 生成的可执行程序体积比较大，比较占资源。 当多个静态链接生成的可执行程序使用同一个库时，内存中会存在大量重复的代码。

---

⛄️2. 静态库的打包与使用

❄️ 2.1 静态库的打包

静态库打包的本质：把你的代码生成的二进制.o文件进行打包。

下面我们用简单的加法和减法来做演示

my_add.h

#pragma once
#include

int my_add(int a,int b);

1
2
3
4
5

my_add.c

#include"my_add.h"

int my_add(int a,int b)
{
    return a+b;
}

1
2
3
4
5
6
7

my_sub.h

#pragma once
#include

int my_sub(int a,int b);

1
2
3
4
5

my_sub.c

#include"my_sub.h"

int my_sub(int a,int b)
{
    return a-b;
}

1
2
3
4
5
6
7

下面我们来将这四个文件进行打包然后生成一个静态库

• 第一步

将所有的源文件变成对应的.o目标文件

---

• 第二步

使用ar命令将所有的目标文件打包生成静态库

注意：

ar命令是gnu的归档工具，它常用于将目标文件打包为静态库，ar命令中的-r选项与-c选项分别代表的是repalce和creat。

• -r（replace）：若静态库文件当中的目标文件有更新，则用新的目标文件替换旧的目标文件。
• -c（creat）：建立静态库文件。
• -t：列出静态库重点文件
• -v（verbose）：详细信息

---

• 第三步

将生成的静态库文件与目标文件对应的头文件组织起来

当我们将我们自己的库给别人使用的时候，我们需要创建两个目录，一个用来存放所有的头文件，一个用来存放静态库文件。

因此，我们将myadd.h与mysub.h这两个头文件放到include这个目录下。将静态库文件放到lib这个目录下。然后将这两个目录都放到mylib这个目录下，此时我们若是向把我们自己的库给别人使用，我们只需要将mylib这个文件发给别人就可以了。

注意：

Mac下没有tree命令，而window下是有的，需要下载

sudo yum -y install tree
1

---

❄️ 2.2 静态库的使用

静态库生成好了之后，我们就来尝试着使用以下这个静态库吧。

我们首先创建一个test.c文件，然后写一段简单的代码用一下加法函数

text.c

#include"my_add.h"
int main()
{
    int x = 10;
    int y = 20;
    printf("add: %d\n",my_add(x,y));
    return 0;
}

1
2
3
4
5
6
7
8
9

Makefile

text:text.c
	gcc -o $@ $^ -static
    
.PHONY:clean
clean:
	rm -f text

1
2
3
4
5
6
7

• 方法一

使用gcc选项

我们发现居然出错了，我们打包好的静态库和头文件不就在当前目录下嘛，为什么它这里却又说找不到呢？

这是因为编译器它并不知道你所包含的my_add.h头文件在哪里，所以我们需要指定头文件的搜索路径。

因此我们需要在makefile里面的gcc后面带一个选项就可以指定头文件的搜索路径了

-I：指定头文件的搜索路径

修改完之后我们重新make一下

我们发现又出错误了

这是因为你只是告诉了编译器库文件的搜索路径在哪里，但是你并没有告诉你要去链接哪一个库，假如说这个库文件里面有很多个库，那编译器它又怎么知道你想要去链接哪个库呢。

这是因为头文件my_add.h里面只有加法函数的声明，并没有函数的定义，因此我们还需要指定库文件的搜索路径。

因此我们只需要在makefile里面的gcc后面带一个选项就可以指定库文件的搜索路径了

-L：指定库文件搜索路径

我们接着再来make一下

我们发现又出错误了

这是因为你只是告诉了编译器库文件的搜索路径在哪里，但是你并没有告诉你要去链接哪一个库，假如说这个库文件里面有很多个库，那编译器它又怎么知道你想要去链接哪个库呢?

所以我们还需要指定一下我们需要链接库文件中的哪一个库。

因此我们需要在makefile里面的gcc后面再带一个选项去指明我们想要链接库文件中的哪一个库。

l：指明想要链接库文件中的哪一个库

我们再来make一下看看结果

最终我们得到了我们想要的运行结果。

注意： 所有的库和头文件只有在当前路径下能够被直接找到，如果当前路径下还包了目录，那么你就需要指明你的搜索路径才行。

• 方法二

将头文件和库文件放到系统路径下

如果我们不指定搜索路径的话，编译器它就找不到我们的头文件和库文件，除了上面指定搜索路径的法子我们还可以将我们的头文件和库文件放到系统路径下，这样的话编译器就能够找到了。

尽管使用这种方式我们不需要指定头文件的搜索路径和库文件的搜索路径，但是我们还是要告诉编译器我们链接库文件的哪个库。

虽然说这种方法相较于第一种方法而言会简单一点，但是我不建议你使用这种方法，原因有两个：

• 将我们的头文件和库文件放到系统路径下，这样做有可能会对系统文件造成污染
• 使用第一种方法可以帮你熟悉gcc命令，同时使用第一种方法虽然麻烦但是不会对系统文件造成污染。

---

⛄️3. 动态库的使用与打包

❄️ 3.1 动态库的打包

我们上面学了静态库的打包和使用之后，接下来我们再来学习动态库的打包和使用就会容易很多了。因此动静态库的打包基本类似。下面我们继续使用这四个文件来给大家展示动态库的打包和使用

• 第一步

让所有的源文件生成对应的.o目标文件

fPIC 产生位置无关码(position independent code)

---

• 第二步

将目标文件打包生成动态库

然后我们来make一下生成对应的目标文件和动态库：

---

• 第三步

将头文件和我们生成的动态库组织起来

这里我们换一种方式来将它们两个组织起来，我们在Makefile里面编写一段代码，通过 发布 然后将他们给组织起来。

下面我们来make output一下，通过发布将头文件和动态库给组织起来：

此时我们的动态库和头文件就已经打包完毕了，如果后面别人想要用我们的这个库，我们只需要把mylib这个文件给别人就可以了。

---

❄️ 3.2 动态库的使用

上面我们的动态库打包好之后，我们就来使用一下我们打包好的动态库吧，下面我们依然使用test.c文件来为大家演示动态库的使用

text.c

#include"my_add.h"
#include"my_sub.h"

int main()
{
    int a = 20;
    int b = 10;
    printf("add: %d\n",myadd(a,b));
    printf("sub: %d\n",mysub(a,b));
    
    return 0;
}

1
2
3
4
5
6
7
8
9
10
11
12
13

Makefile:

test:text.c
	gcc -o $@ $^ -I./mylib/include -L./mylib/lib  -lmy_math    
    
.PHONY:clean
clean:
	rm -f test 


1
2
3
4
5
6
7
8

可以看到我们这里执行可执行程序的时候出错了，这个时候我就比较好奇了：我明明已经指定头文件的搜索路径，指定库文件的搜索路径，以及我们要链接库文件中的哪一个，为什么我们这里还是会报错呢？

这是因为你只是告诉了编译器，你并没有告诉操作系统。不要忘了链接动态库的时候是在程序运行的时候链接的。

可以看到当我们用ldd命令查看test可执行程序的时候，发现找不到这个动态库

那么问题又来了：我们应该如何解决呢？

• 方法一

与静态库使用的第二种方法类似，我们将动态库拷到系统路径下。

• 方法二

更改LD_LIBRARY_PATH

LD_LIBRARY_PATH是程序运行时帮我们找动态库的路径的，因此我们将该动态库所在目录路径添加到LD_LIBRARY这个环境变量中就可以了

# export LD_LIBRARY_PATH=路径
1

可以看到我们现在再使用ldd命令的时候就可以找到该动态库了。

下面我们来执行一下这个可执行程序吧

---