摘要:和luster学习在Linux创建库函数
3.1.2. 文件系统中函数库文件的位置
共享函数库文件必须放在一些特定的目录里，这样通过系统的环境变量设置，应用程序才能正确的使用这些函数库。大部分的源码开发的程序都遵循GNU的一些标准，我们可以看info帮助文件获得相信的说明，info信息的位置是：info:standards#Directory_Variables。GNU标准建议所有的函数库文件都放在/usr/local/lib目录下，而且建议命令可执行程序都放在/usr/local/bin目录下。这都是一些习惯问题，可以改变的。
文件系统层次化标准FHS（Filesystem Hierarchy Standard）（http://www.pathname.com/fhs）规定了在一个发行包中大部分的函数库文件应该安装到/usr/lib目录下，但是如果某些库是在系统启动的时候要加载的，则放到/lib目录下，而那些不是系统本身一部分的库则放到/usr/local/lib下面。
上面两个路径的不同并没有本质的冲突。GNU提出的标准主要对于开发者开发源码的，而FHS的建议则是针对发行版本的路径的。具体的位置信息可以看/etc/ld.so.conf里面的配置信息。
3.2. 这些函数库如何使用
在基于GNU glibc的系统里，包括所有的linux系统，启动一个ELF格式的二进制可执行文件会自动启动和运行一个program loader。对于Linux系统，这个loader的名字是/lib/ld-linux.so.X（X是版本号）。这个loader启动后，反过来就会load所有的其他本程序要使用的共享函数库。
到底在哪些目录里查找共享函数库呢？这些定义缺省的是放在/etc/ld.so.conf文件里面，我们可以修改这个文件，加入我们自己的一些特殊的路径要求。大多数RedHat系列的发行包的/etc/ld.so.conf文件里面不包括/usr/local/lib这个目录，如果没有这个目录的话，我们可以修改/etc/ld.so.conf，自己手动加上这个条目。
如果你想覆盖某个库中的一些函数，用自己的函数替换它们，同时保留该库中其他的函数的话，你可以在/etc/ld.so.preload中加入你想要替换的库（.o结尾的文件），这些preloading的库函数将有优先加载的权利。
当程序启动的时候搜索所有的目录显然会效率很低，于是Linux系统实际上用的是一个高速缓冲的做法。Ldconfig缺省情况下读出/etc/ld.so.conf相关信息，然后设置适当地符号链接，然后写一个cache到/etc/ld.so.cache这个文件中，而这个/etc/ld.so.cache则可以被其他程序有效的使用了。这样的做法可以大大提高访问函数库的速度。这就要求每次新增加一个动态加载的函数库的时候，就要运行ldconfig来更新这个cache，如果要删除某个函数库，或者某个函数库的路径修改了，都要重新运行ldconfig来更新这个cache。通常的一些包管理器在安装一个新的函数库的时候就要运行ldconfig。
另外，FreeBSD使用cache的文件不一样。FreeBSD的ELF cache是/var/run/ld-elf.so.hints，而a.out的cache责是/var/run/ld.so.hints。它们同样是通过ldconfig来更新。
3.3. 环境变量
各种各样的环境变量控制着一些关键的过程。例如你可以临时为你特定的程序的一次执行指定一个不同的函数库。Linux系统中，通常变量LD_LIBRARY_PATH就是可以用来指定函数库查找路径的，而且这个路径通常是在查找标准的路径之前查找。这个是很有用的，特别是在调试一个新的函数库的时候，或者在特殊的场合使用一个肥标准的函数库的时候。环境变量LD_PRELOAD列出了所有共享函数库中需要优先加载的库文件，功能和/etc/ld.so.preload类似。这些都是有/lib/ld-linux.so这个loader来实现的。值得一提的是，LD_LIBRARY_PATH可以在大部分的UNIX-linke系统下正常起作用，但是并非所有的系统下都可以使用，例如HP－UX系统下，就是用SHLIB_PATH这个变量，而在AIX下则使用LIBPATH这个变量。
LD_LIBRARY_PATH在开发和调试过程中经常大量使用，但是不应该被一个普通用户在安装过程中被安装程序修改，大家可以去参考http://www.visi.com/~barr/ldpath.html,这里有一个文档专门介绍为什么不使用LD_LIBRARY_PATH这个变量。
事实上还有更多的环境变量影响着程序的调入过程，它们的名字通常就是以LD_或者RTLD_打头。大部分这些环境变量的使用的文档都是不全，通常搞得人头昏眼花的，如果要真正弄清楚它们的用法，最好去读loader的源码（也就是gcc的一部分）。
允许用户控制动态链接函数库将涉及到setuid/setgid这个函数如果特殊的功能需要的话。因此，GNU loader通常限制或者忽略用户对这些变量使用setuid和setgid。如果loader通过判断程序的相关环境变量判断程序的是否使用了setuid或者setgid，如果uid和euid不同，或者gid和egid部一样，那么loader就假定程序已经使用了setuid或者setgid，然后就大大的限制器控制这个老链接的权限。如果阅读GNU glibc的库函数源码，就可以清楚地看到这一点，特别的我们可以看elf/rtld.c和sysdeps/generic/dl-sysdep.c这两个文件。这就意味着如果你使得uid和gid与euid和egid分别相等，然后调用一个程序，那么这些变量就可以完全起效。
luster
luster@linuxaid.com.cn,hwang@ustc.edu
