linux动态库问题

Posted 2023-04-22

linux静态库中每个函数都做一个.o，以减少内存的消耗。
但是动态库中却包含了大量的函数，假设我只使用了printf函数，但是却加载了整个libc.so.这样不是内存的浪费吗。
另外gcc编译的时候，如果用到了printf函数，gcc是扫描整个libc.so吗？这样不是编译的速度很慢？

1、虽然动态库有点浪费内存，但是动态库最大的作用是：减少占用磁盘空间，减少开发时的编译时间，而不是你想的编译速度慢。因为采用了动态库，所以如果我修改了动态库，我只需要编译动态库。而如果采用了静态库，如果修改了静态库，那么，所有用了该静态库的程序和静态库都必须重新编译。而且gcc不是扫描整个libc.so文件。因为so文件里有符号表，哪个符号在哪个.o文件里，只要扫描符号表就知道了，而且由于他不需要从so文件中拷贝使用的函数，从某种意义上来说编译速度比静态库更快。
2、动态库的加载采用写时拷贝技术，即：只有当我用这个函数的时候我才把该函数部分拷贝过来，它不会拷贝整个so文件，只会拷贝需要的部分。 参考技术A 但是动态库中却包含了大量的函数，假设我只使用了printf函数，但是却加载了整个libc.so.这样不是内存的浪费吗。
libc中的函数都是常用的.而且动态库是所有进程共享的.即使整个库都加载了,你的进程用不到,其他进程还会用到的.

如果某个你自己的动态库只有你自己的进程用,那么我相信你就不会再库中编译很多你用不到的函数来浪费内存了.

一个动态库文件不仅包含真正需要拷贝到内存中的机器码,还包含一些其他的信息.比如函数索引.
另外gcc编译的时候只会扫描库的索引,而不是去扫描整个库文件. 参考技术B 动态库的作用：
节省磁盘和内存空间，还可以减少物理内存页面的换入换出，也可以增加CPU缓存的命中率；
程序的升级变得更加容易；
便于不同的开发者和开发组织之间独立进行开发和测试；

至于你的疑问：
1. 只使用printf函数，系统只会加载libc.so的printf所在的页；所以操作系统管理内存是按照页来管理的，操作系统为进程建立内存和虚拟空间的映射，以及虚拟地址空间和磁盘文件（可执行程序）的映射，并且操作系统提供了写时拷贝技术；也就是只有真正运行了printf函数时，操作系统才将libc.so中的printf函数所在的页加载到内存（通过以上两个映射来做）
所以不存在你的内存浪费的问题；

2. 使用printf函数，在编译时，这里需要扫面整个libc.so，静态库也一样；
链接时，可执行程序只保存了printf符号(PIC，地址无关代码)，和libc.so库名称；
运行时，动态加载器需要遍历可执行程序所使用的所有地址无关代码，并且记载所有的so库（加载到进程虚拟地址空间，实际上还没有加载到内存），将printf与实际的so库虚拟地址关联；
这里当程序运行printf时，需要进行间接地址访问到so库的地址，所以效率上比静态库低（静态库是直接地址访问）
并且，由于动态库需要动态加载器的加载过程，而静态库不需要，所以运行效率没有静态库方式高；

希望以上的解答可以给你帮助。另外，如果你还有其他疑惑，你可以去看下《程序员的自我修养》这本书，里面讲的比较详细。

如果你有其他疑问，尽快在这里问，我懂的话，都可以给你解答

参考资料：《程序员的自我修养》

Linux动态链接库.so文件的命名及用途总结

[转]https://blog.csdn.net/zhanglianpin/article/details/50491958

我们在linux下开发项目，有时会对外提供动态库，像***.so.1.0.0这样子的文件，另外提供相应的头文件。用户拿到动态库和头文件说明，就可以使用动态库里的function。

那随之而来的一个问题是，动态库的升级问题，我们的动态库更改了一个bug，升级了一个版本，那使用我们动态库的应用程序需要重新编译吗？运行时会产生异常吗？linux下是怎么规范这些内容的呐？

大家一定听说过windows下的dll hell。

Linux中的.so文件 是动态链接的产物 
共享库理解为提供各种功能函数的集合，对外提供标准的接口
Linux中命名系统中共享库的规则

主版本号：不同的版本号之间不兼容
次版本号：增量升级 向后兼容
发行版本号：对应次版本的错误修正和性能提升，不影响兼容性

下面说说linux下动态库的命名规范。

 

为方便管理依赖关系，创建或部署共享库时，必须遵循统一约定的规则才行，其中包括动态库的命名规则及其部署方式。

共享库命名约定

1) 每个动态库有一个包含了真正的库代码的文件名，通常被称为库的 realname ，命名格式通常为

libxxx.so.x.y.z，其中so后缀中的x为主版本号，y为副版本号，z为发行版本号。例如，我的linux系统机器上zlib共享库的realname为     libz.so.1.2.8，这个文件是含有可执行的二进制代码的。

2) 每个动态库都有一个以"lib"为前缀且以".so.x"为结尾的被称为 soname

 

的特定名称，其中x为主版本号，soname命名格式通常为libxxx.so.x。例如，我的linux系统机器上zlib共享库的soname为libz.so.1。这个soname包含了动态库的主版本号，这个doname一般会包含在库代码的头文件中，这个可以使用 readelf -d 读取出来，使用这个动态库的程序的二进制ELF的头文件中包含有这个动态库的soname。程序运行时会按照这个名称去找真正的库文件。

3) 此外，编译链依赖了共享库的应用模块时，链接器只认不带任何版本号的共享库名， 可以将库名称作" linker name。

例如，我的linux系统机器上zlib共享库的linkername为libz.so。也即，链接使用了动态库的程序时查找的动态库名称。例如：gcc -o test test.o -lz , 链接时就会找libz.so 。若没有这个文件，链接器就报错。

下面的内容转自：http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

以实际例子的形式，详细地阐述了realname soname linkername 之间的关系。

 

添加动态链接库路径

 

1. 连接和运行时库文件搜索路径到设置

库文件在连接（静态库和共享库）和运行（仅限于使用共享库的程序）时被使用，其搜索路径是在系统中进行设置的。一般 Linux 系统把 /lib 和 /usr/lib 两个目录作为默认的库搜索路径，所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库，需要将库的位置添加到库的搜索路径之中。设置库文件的搜索路径有下列两种方式，可任选其一使用：

 

(1). 在 /etc/ld.so.conf 文件中添加库的搜索路径。(或者在/etc/ld.so.conf.d 下新建一个.conf文件，将搜索路径一行一个加入-junziyang)

将自己可能存放库文件的路径都加入到/etc /ld.so.conf中是明智的选择添加方法也极其简单，将库文件的绝对路径直接写进去就OK了，一行一个。例如：

1 2 3

/usr/X11R6/lib /usr/local/lib /opt/lib

　 需要注意的是：这种搜索路径的设置方式对于程序连接时的库（包括共享库和静态库）的定位已经足够了，但是对于使用了共享库的程序的执行还是不够的。这是因为为了加快程序执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率，所以是直接读取库列表文件 /etc/ld.so.cache 从中进行搜索的。/etc/ld.so.cache 是一个非文本的数据文件，不能直接编辑，它是根据 /etc/ld.so.conf 中设置的搜索路径由 /sbin/ldconfig 命令将这些搜索路径下的共享库文件集中在一起而生成的（ldconfig 命令要以 root 权限执行）。

 因此，为了保证程序执行时对库的定位，在 /etc/ld.so.conf 中进行了库搜索路径的设置之后，还必须要运行 /sbin/ldconfig 命令更新 /etc/ld.so.cache 文件之后才可以。ldconfig ,简单的说，它的作用就是将/etc/ld.so.conf列出的路径下的库文件缓存到/etc/ld.so.cache 以供使用。因此当安装完一些库文件，(例如刚安装好glib)，或者修改ld.so.conf增加新的库路径后，需要运行一下 /sbin/ldconfig使所有的库文件都被缓存到ld.so.cache中，如果没做，即使库文件明明就在/usr/lib下的，也是不会被使用的，结果编译过程中抱错，缺少xxx库，去查看发现明明就在那放着，搞的想大骂computer蠢猪一个。

 在程序连接时，对于库文件（静态库和共享库）的搜索路径，除了上面的设置方式之外，还可以通过 -L 参数显式指定。因为用 -L 设置的路径将被优先搜索，所以在连接的时候通常都会以这种方式直接指定要连接的库的路径。 

这种设置方式需要 root 权限，以改变 /etc/ld.so.conf 文件并执行 /sbin/ldconfig 命令。而且，当系统重新启动后，所有的基于 GTK2 的程序在运行时都将使用新安装的 GTK+ 库。不幸的是，由于 GTK+ 版本的改变，这有时会给应用程序带来兼容性的问题，造成某些程序运行不正常。为了避免出现上面的这些情况，在 GTK+ 及其依赖库的安装过程中对于库的搜索路径的设置将采用另一种方式进行。这种设置方式不需要 root 权限，设置也简单。

(2). 在环境变量 LD_LIBRARY_PATH 中指明库的搜索路径。

 

设置方式：

1	export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH

可以用下面的命令查看 LD_LIBRAY_PATH 的设置内容：

1	echo $LD_LIBRARY_PATH

至此，库的两种设置就完成了。

 

查看程序使用的动态库

ldd  <可执行程序>