建设工程考试官方网站,夜狼seo,app开发公司tianpinkeji,网站如何做图片自动切换动静态库 一、静态库1. 静态库概念2. 制作静态库#xff08;1#xff09;朴素方法 --- 不打包#xff08;2#xff09;对静态库打包 3. 使用静态库#xff08;1#xff09;朴素方法 --- 直接使用#xff08;2#xff09;使用打包好的静态库 二、动态库1. 动态库概念2. … 动静态库 一、静态库1. 静态库概念2. 制作静态库1朴素方法 --- 不打包2对静态库打包 3. 使用静态库1朴素方法 --- 直接使用2使用打包好的静态库 二、动态库1. 动态库概念2. 制作动态库3. 使用动态库1头文件和库文件安装到系统中2软链接3环境变量4更改关于动态库的配置文件 三、动态库加载1. 引入概念2. 理解动态库加载3. 程序的运行过程 一、静态库 1. 静态库概念 静态库.a程序在编译链接的时候把库的代码链接到可执行文件中。程序运行的时候将不再需要静态库。 2. 制作静态库 1朴素方法 — 不打包 下面我们实现两个简单的方法加法和减法的计算方法使用头文件和源文件分开的形式呈现出来例如 那么这一堆头文件和源文件该如何形成一个静态库给别人使用呢注意我们打包的库中是没有 main 函数的我们也不能把 main 函数打入库中。 接下来我们在该目录下创建一个测试以上方法的主函数 TestMain.c 假设现在我们需要将上面的所有文件形成一个可执行程序测试该如何编译呢使用 gcc如 如上图为什么我们在编译的时候没有编译头文件呢因为头文件在当前路径下所以编译器 gcc 是可以直接找到的 那么对于上面形成的可执行程序我们也是可以正常运行的如下 其实实际上我们形成可执行程序我们不建议把所有的源文件直接全部编译因为这样的话每一个源文件都要经过预处理、编译、链接等。所以一般情况下对于这种多文件项目时要先把源文件编译成 .o 文件然后再把所有的 .o 文件进行链接形成可执行程序 所以我们先创建一个 Makefile进行对上面的实践 如上图我们解释一下各项的作用。首先第1、2行不需要解释因为这是我们常用的语法但是所有的 .o 文件在当前目录下并不存在所以还需要形成下面的依赖关系。对于 %.o:%.c首先 %.c 就是将当前路径下的所有 .c 文件一个一个展开经过 gcc -c $ 形成一个一个同名的 .o 文件。其中 $^ 和 $ 的区别在于$^ 是将冒号右边的所有文件看作一个整体形成冒号右边的程序而 $ 是将冒号右边的一个一个分开编译形成一个一个的冒号右边的程序。 接下来我们编译一下就形成了一堆的 .o 和可执行程序 所以我们想要形成一个库我们就需要将上面的所有源文件和 main 函数和 Makefile 全部删除将剩下的所有 .o 和头文件打包即可。然后使用者就可以将它自己写的 main 函数编译成 .o 文件和我们的 .o 文件一链接即可 接下来我们将代码逻辑修改一下首先新建一个目录 user 将用户写的主函数放进去 接下来我们形成 .o 文件和头文件给到 user我们暂时先不将这些文件进行打包 所以使用者就可以自己将 main 函数形成 .o 文件再和我们的文件链接即可使用 但是这样对于用户来说太麻烦了所以我们需要将所有的 .o 文件打包生成库。首先现在我们先需要生成静态库而生成静态库的命令为(假设以我们上面的文件打包为例) ar -rc libmylib.a Add.o Sub.o其中 ar 命令是将所有的 .o 文件形成库文件的过程选项 -rc 代表如果 .o 文件存在则替换不存在则创建。而 libmylib.a 是静态库库要以 lib 开头所以我们的库的真正名字是 mylib. 下面我们使用 Makefile 生成一个静态库 static_liblibmylib.a$(static_lib):Add.o Sub.oar -rc $ $^%.o:%.cgcc -c $.PHONY:cleanclean:rm -f *.o *.a如上图首先我们为该静态库的名字设置一个变量 static_lib 然后下面使用 .o 文件生成该静态库。 所以我们得出结论静态库的本质就是将库中的源代码直接翻译成 .o 目标二进制文件然后打包 2对静态库打包 下面我们对静态库和头文件分别进行打包对 Makefile 进行修改如下 static_liblibmylib.a$(static_lib):Add.o Sub.oar -rc $ $^%.o:%.cgcc -c $.PHONY:outputoutput:mkdir -p mylib/includemkdir -p mylib/lib cp -f *.h mylib/includecp -f *.a mylib/lib .PHONY:cleanclean:rm -rf *.o *.a mylib我们多加了一个伪目标就是用来发布我们的静态库的本质就是创建一个目录把头文件放入 include 中把库文件放入 lib 中。我们直接发布会形成一个库 我们使用 tree 查看一下该库 生成了对应的静态库之后我们需要给别人使用所以我们也可以对该库进行打包 然后将该打包的文件给别人即可。 3. 使用静态库 1朴素方法 — 直接使用 上面我们可以形成静态库了那么我们该如何使用别人的静态库呢现在我们回到用户的角度我们只有一个主函数 我们现在需要用到库中的方法直接编译是会报错的因为我们还没有对应的库。所以我们先使用最朴素的方法先不进行打包。我们将所有的头文件给到用户 还需要将对应的静态库给到用户 如上我们对应的头文件和静态库都有了所以我们尝试编译一下 我们发现出现了链接错误这是为什么呢现在我们需要知道我们自己写的库或者别人写的库叫做第三方库而 gcc 默认不认识所以我们需要在 gcc 中加上 -l 选项让编译器去链接指定的库如下 gcc TestMain.c -l mylib其中-l 后面带的是库的真正的名字即去掉前面的 lib 和后缀 .a我们尝试链接一下 但是我们发现它还是找不到库。所以我们还需要加上一个选项 -L后面跟上该库的路径如下 如上图我们就生成了可执行程序。 但是为什么我们以前生成可执行程序的时候不需要指定库名称和库路径呢因为 gcc 就是默认处理C语言的所以C标准库不需要指定链接哪个库还有路径它自身就会帮我们找到并链接。 接下来我们使用 ldd 查看该可执行程序依赖的库文件 如上图为什么我们的程序没有依赖到 mylib 的库呢那是因为我们的可执行程序默认是动态链接的ldd 是只能查动态库的而静态库已经被拷贝到可执行程序里了gcc 默认是动态链接的但个别库如果我们只提供 .agcc 也会局部性的把我们指定的 .a 进行静态链接其它库正常动态链接如果加上 -static 选项gcc 就只能链接 .a。 2使用打包好的静态库 我们在上面已经生成了一个打包好的静态库现在我们将该压缩文件拿到用户这里 然后对该压缩文件进行解压 如上我们就把静态库拿到手了。然后我们就可以将该库安装一下怎么安装呢系统搜索头文件默认是在 /usr/include 这样的目录下的而库文件一般都是在 /lib64 目录下的所以我们将第三方库安装本质就是将所有的头文件拷贝到 /usr/include 路径下将所有的库文件拷贝到 /lib64 路径下 但是我们也可以选择不这样做我们还有另一种方法我们可以直接使用。首先我们先看看直接编译会有什么问题 首先出现的问题是头文件找不到的问题有一种方法可以直接在代码中使用头文件时带上路径例如 #include mylib/include/Add.h但是我们不选择这样做因为这样不太好。那么现在我们的头文件既不在当前目录下也不在系统路径下没关系我们可以在 gcc 中带上选项 -I后面带上头文件的路径即可意思就是告诉 gcc 编译器除了在上面两个路径下找之外还需要在我们指定的路径下找那么我们尝试编译一下 那么现在就不会报头文件的错误了而是链接报错了。那么这个报错我们在上面已经解决过了只需要带上 -l 指定库名称和带上 -L 指定库文件的路径即可如下 gcc TestMain.c -I mylib/include/ -l mylib -L mylib/lib/如上我们就能使用别人制作的静态库了。如果我们将头文件和库文件都安装到系统中了-I 和 -L 就不需要带了。 二、动态库 1. 动态库概念 动态库.so程序在运行的时候才去链接动态库的代码多个程序共享使用库的代码。 2. 制作动态库 首先我们需要介绍一下生成动态库使用的指令是 gcc带上 -shared 选项即可。另外在生成 .o 文件的时候需要带上 -fPIC 选项意思是产生位置无关码这个我们后面再解释。动态库的库名规则libxxx.so。 接下来我们修改一下 Makefile 文件如下 dynamic_liblibmylib.so $(dynamic_lib):Add.o Sub.ogcc -shared -o $ $^%.o:%.cgcc -fPIC -c $.PHONY:outputoutput:mkdir -p mylib/includemkdir -p mylib/lib cp -f *.h mylib/includecp -f *.so mylib/lib .PHONY:cleanclean:rm -rf *.o *.so mylib接下来我们编译一下 如上图就多了一个动态库文件接下来我们 make output 发布起来当前目录就会生成一个动态库我们可以 tree 查看一下 如上头文件就包含在 include 中库文件就包含在 lib 中。 接下来我们就可以将该动态库给别人使用了现在我们将该动态库拷贝到 user 目录下 现在别人就可以使用我们的库了。 3. 使用动态库 接下来我们按照使用静态库的方式尝试使用动态库首先先生成可执行程序 接下来我们开始运行 我们会发现报错了报的是不能打开该动态库找不到该文件或目录。这是为什么呢我们不是将路径和库名称都告诉 gcc 了吗 首先动态库是可执行程序和库分离开的我们的可执行程序加载到内存中了但是库还没有加载到内存中。而静态库是直接拷贝到可执行程序中的所以它们会被一起加载到内存中。也就是说动态链接非常依赖这个动态库 而我们在上面将路径和库名称都告诉了编译器但是程序已经形成了编译器的工作周期已经结束了接下来运行的时候和编译器就没有关系了那么接下来就和系统有关系了所以当我们加载运行的时候我们也要告诉系统动态库在哪里 我们可以使用 ldd 观察一下 我们发现我们的动态库是找不到的。 所以解决方法有如下几种 1头文件和库文件安装到系统中 既然在系统默认的搜索路径下找不到我们的库文件和头文件我们就将它们拷贝到系统的默认搜索路径中。 先拷贝头文件 sudo cp mylib/include/*.h /usr/include/再拷贝库文件 sudo cp mylib/lib/*.so /lib64然后我们在系统的目录中可以查看一下我们拷贝的文件 如上图我们的库文件和头文件已经拷贝到系统中了。接下来我们可以重新生成可执行程序现在我们就不需要带路径了只需要指定库名称即可 然后我们也可以直接运行可执行程序了 ldd 也能看到它能找到对应的库了 2软链接 我们还可以通过在当前目录下建立软链接的方式找到库文件从而执行可执行程序。如下 ln -s mylib/lib/libmylib.so libmylib.so我们发现当前路径下的软链接是可以被找到的那么就说明动态链接默认会在当前路径下搜索库文件 ldd 查看 3环境变量 我们知道系统在运行的时候会去帮我们找我们的库去哪里找呢除了系统默认库路径下去找还会去 LD_LIBRARY_PATH 加载库的环境变量中去找 所以我们将库文件所在的路径添加到 LD_LIBRARY_PATH 中即可。接下来我们尝试一下首先我们需要找到该库对应的路径 系统是知道我们需要链接哪一个库的只是找不到它在哪里所以只需要给它所在的路径即可不需要包含库名字了。接下来我们导一下环境变量再查看 LD_LIBRART_PATH 下的环境变量就可以找到了 添加之后是即时生效的这时候系统就知道我们的库的路径了 接下来我们的可执行程序也就可以执行了 但是当前这种方法导环境变量是内存级的当我们退出后重新进入它就没了所以我们想永久生效的话还需要去改有关环境变量的配置文件这里就不再介绍了。 4更改关于动态库的配置文件 在系统中存在一个 /etc/ld.so.conf.d/ 这样的一个配置文件目录这是系统管理所有系统动态库加载相关的配置文件。如下 我们可以任意查看一个文件内部的内容是什么 我们会发现它里面的内容只有一个路径就是我们需要查找的动态库所对应的路径所以我们想要自己的动态库永久有效只需要在 /etc/ld.so.conf.d/ 目录下创建一个文件在该文件中写入我们动态库的路径即可 下面我们尝试一下现在 /etc/ld.so.conf.d/ 目录下新建文件 sudo touch /etc/ld.so.conf.d/temp.conf然后进入该文件添加我们动态库的路径 如上我们添加成功一般来说也是即时生效的。如果没有生效我们使系统在加载配置上进行刷新 sudo ldconfig此时我们查看的时候就生效了 此时可执行程序也可以运行了 所以我们从网上下载的第三方库的原理就是将一系列的头文件和库文件拷贝到系统的默认搜索路径下 另外如果别人给我们的库中既包含动态库也包含静态库即同一个库中提供动静态两种库gcc 默认使用动态库 使用 Makefile 生成多个可执行程序 上面我们都是使用 Makefile 生成一个动态库和一个静态库接下来我们要使用 Makefile 一次性生成动态库和静态库下面直接参考 Makefile 文件 static_liblibmylib.adynamic_liblibmylib.so .PHONY:allall:$(dynamic_lib) $(static_lib)$(static_lib):Add.o Sub.oar -rc $ $^%.o:%.cgcc -c $$(dynamic_lib):Add.o Sub.ogcc -shared -o $ $^%.o:%.cgcc -fPIC -c $.PHONY:outputoutput:mkdir -p mylib/includemkdir -p mylib/lib cp -f *.h mylib/includecp -f *.a mylib/lib cp -f *.so mylib/lib .PHONY:cleanclean:rm -rf *.o *.so *.a mylib三、动态库加载 1. 引入概念 我们上面在形成动态库时还有一个问题没有讲那就是 gcc -fPIC -c xxx.c 中的 -fPIC 选项它的意思是与位置无关码到底是什么意思呢接下来我们需要了解一下。 首先我们要知道在 Linux 下形成的可执行程序是 ELF 格式的可执行程序它其中包含有一张类似于符号表的东西里面包含各种函数依赖的库以及地址符号表就是动态链接这些动态库的。当我们需要将可执行程序加载到内存中时动态链接的程序不光光自己要加载链接的库也要加载到内存中 然后我们要知道程序没有被加载到内存的时候程序内部有地址吗有的当我们的程序编译成为二进制文件之后变量名、函数名等还有吗没有了编译的时候对代码进行编址基本遵守虚拟地址空间那一套虚拟地址空间不仅仅是操作系统里面的概念编译器编译的时候也要按照这样的规则编译可执行程序这样才能在加载的时候进行从磁盘文件到内存再进行映射。所以在程序没有被加载到内存的时候就已经具有了“虚拟地址”通俗地说是逻辑地址这种逻辑地址的概念就是基地址偏移量。这种以基地址从0开始的我们把它叫做平坦模式。 那么基地址偏移量就是可以确定一个段的比如说代码区基地址从0开始偏移量是200那么 [0, 200] 这个段就是代码区。所以这个可执行程序中就会形成许多段它就是采用偏移量的不同这种方式定位每个段的。 在计算机里面对程序进行编址的时候会有两种编址方式一种是绝对编址另一种是相对编址。 绝对地址比较依赖起始位置比如说我们当前站在距离一棵树的20米处我们的起始位置是0那么绝对位置就是我们相对于起始位置的距离但是我们的位置会因为起始位置的变化而发生变化。但是相对地址就是我们的位置相对于这个树的距离当起始位置发生变化的时候我们的位置相对于树也就没有变化这就是相对地址。 绝对编址比较适合我们上面说的那一套可执行执行的逻辑地址而相对编址比较适合形成库中函数的地址因为库中我们把函数的地址形成之后所有库中的函数里面只需要记录它自己相比较于库的起始的偏移量是多少只记录偏移量所以未来这个库在内存的任意位置加载库里面的所有函数的地址都不变所以这就叫做与位置无关码 2. 理解动态库加载 接下来我们回到地址空间中理解动态库的加载首先磁盘中有我们的 ELF 可执行程序可执行程序中的符号表中依赖了 libmylib.so 这样的动态库如下图 但是当我们将可执行程序加载到内存中后我们也需要找到该动态库数据和代码肯定是被加载到内存中了而且经过页表映射关系也能建立好。但是动态库也要被加载到内存的所以动态库被加载至内存后也要经过页表映射映射到地址空间中的共享区所以进程可以通过地址空间找到代码和数据并且可以在共享区找到动态库中的代码。可以结合下图理解 也就是说库被加载后要被映射到指定使用了该库的进程的地址空间中的共享区部分。那么我们可以保证每次都能将动态库映射到固定的地址空间吗并不是的。但是我们想做到让库在共享区的任意位置都可以正确运行呢 下面我们先了解一下我们动态库中的方法是如何编址的其实就是以 库名称方法偏移量 来确定的。也就是当可执行程序用到动态库中的方法时它只需要记录在哪个库里面在这个库的偏移量是多少即可例如下图 当可执行程序加载到内存中代码和数据也加载到内存中后当执行执行的时候发现需要用到库中的方法时也要把该库加载到内存里然后经过页表映射到进程地址空间中一旦库加载之后它在地址空间中的位置就是确定了我们假设该库加载到地址空间后的地址为 0x1111那么我们就可以将库中的符号用 0x1111 替换掉如下图 所以进程在执行代码的时候当识别到库中的方法时该怎么找到库中的方法呢因为我们已经知道库在地址空间所在的位置也知道该方法在库中的偏移量所以就能在地址空间中跳转就可以找到该方法 所以未来动态库在地址空间中的共享区中随意加载都可以了因为我们库中的方法编址方式都是相对编址的方式是相对于该库的偏移量是多少所以无论该库的地址在共享区中如何变化偏移量在该库中是不变的所以我们就能很快地找到对应的方法 所以动态库采用的就是一种相对编址的方式然后就可以做到动态库中的与位置无关性所以以前在 gcc 中形成动态库需要加上 fPIC形成与位置无关码。 3. 程序的运行过程 首先要知道CUP 中有一个指令寄存器当 CUP 需要执行指令时只需要把正文部分的代码直接读到指令寄存器然后让 CUP 执行指令。 我们也能从上面的引入概念中知道程序没有被加载的时候程序内部就已经有地址了即在磁盘的时候就已经有虚拟地址了已经被编译好了。也就是说在磁盘的时候可执行程序已经将代码、数据编址好了暂时不考虑动态库因为牵扯动态链接。 假设我们的可执行程序中 main 函数的起始地址为 0x11111111然后我们的代码中还调用了其它方法假设有两个方法地址分别为 0x2222 和 0x3333如下图 而上面的地址可以说是虚拟地址其实是可以看成是起始地址偏移量只是统一编址的时候起始地址从0编址也就是可以看成是 0: 11111111、0: 2222、0: 3333我们一般把这种地址叫做逻辑地址但它实质上还是地址空间上的虚拟地址。 当可执行程序加载到内存后程序内的地址不变那么可执行程序的代码加载到内存需要占据物理内存吗要的所以它一定要有自己对应的物理地址所以该可执行程序的代码每一段都需要有自己的物理地址如下图 此时加载到内存之后物理地址有了那么页表的右侧就可以填上了。更重要的是ELF 可执行程序会在特定的位置记录下来自己程序的入口地址 entry也就是编译器在编译的时候可执行程序在符号表中有专门的字段记录 main 函数的地址供操作系统读取 那么在程序加载进内存后首个虚拟地址就有了就是 main 函数的地址那么程序在加载进来的时候又有了物理地址所以在最开始时在页表中就可以构建最简单的 k-v 的映射关系。所以当 CUP 执行这个程序的时候操作系统只需要将 main 函数的地址加载到指令寄存器中指令寄存器拿到最开始的程序入口地址它是虚拟地址 0x11111111然后找到进程找到进程地址空间找到页表进行虚拟到物理的转化而在上面已经建立好了虚拟地址到物理地址的 k-v 映射关系所以此时 CUP 就能读取第一条指令了。 然后读取指令时读到了 call 0x2222如果后续的代码和数据不在内存里就重新加载重新构建映射因为起始地址都已经有了剩下的虚拟地址都是连续的因为正文代码区中的代码都是在一起的当读取到 call 0x2222 方法CUP 就读取对应的指令call 方法就要做函数跳转因为 0x2222 也是虚拟地址它也加载到内存中了所以可以根据页表的映射关系找到对应的 A函数然后就可以找到代码和数据。所以整个程序运行时整个虚拟到物理的转化就轮转起来了