在采用动态链接方式对程序进行编译,链接时候。链接程序只是在最终的可执行文件中记录下关于所引用的共享库中的符号的一些登记信息，以便在程序被执行时，动态链接程序能够根据这些登记信息找到相应的代码。因此登记动态链接方式而言，除了在链接阶段涉及到对库文件的搜索路径外，还有一个在程序运行阶段对库文件的搜索问题。
前一个问题我们知道借助于LD_LIBRARY_PATH环境变量及cc命令行中的-L选项已经得到了比较好的解决。对于第二个问题，我们必须提供一种机制，使得动态链接程序能够找到相应的动态库，然后才能将其代码映射到其自己的地址空间中。
UNIX系统中对这些问题的解决实际上采取了类似的方法。程序员可以使用LD_RUN_PATH来解决上面的第二个问题。同PATH变量相同，LD_RUN_PATH的值也是一系列由冒号分隔的绝对路径名组成的。在此环境变量中，我们可以列出所用到的动态库所在的那些目录，一般动态链接程序在程序运行时对这些目录进行搜索。例如，我们可以定义LD_RUN_PATH的值如下：
$ LD_RUN_PATH=$HOME/lib;export LD_RUN_PATH
这里我们在LD_RUN_PATH中只指定了一个目录名。在使用如下命令：
$ cc -L $HOME/lib -o myprog myprog.c -l test
建立可执行文件myprog之后，在shell提示符下输入：
$ myprog ...
在执行此程序时，动态链接程序将根据LD_RUN_PATH中所记录的路径（$HOME/lib),在其中依次搜索有关的动态库libtest.so。
在搜索完LD_RUN_PATH指定的各个目录之后，动态链接程序将根据缺省设置搜索系统标准位置。对于动态链接程序而言，库的标准位置只有/usr/lib。编译系统所提供的库的每一个可执行版本都保留在/usr/lib目录中。
上一节我们介绍过的环境变量LD_LIBRARY_PATH实际上也能起到同样的作用。并且使用此环境变量还有一个好处就是在链接生成了可执行文件之后，可以把此可执行文件用到的共享库移至另一个目录中，不必重新对程序进行链接。只需恰当地设置LD_LIBRARY_PATH的值，仍然可以让动态链接程序找到相应的动态库。
仍以上例来说明这个问题。假定在生成了myprog文件之后，我们将libtest.so移至另外一个目录$HOME/sharedlib下。此时仅仅将LD_RUN_PATH的值设成是$HOME/sharedlib是不行的，因为编译产生的可执行程序将无法使用$HOME/sharedlib目录下的libtest.so。但可以在LD_LIBRARY_PATH中指定新的目录。
$LD_LIBRARY_PATH= $HOME/sharedlib;export LD_LIBRARY_PATH
这样再执行myprog时，动态链接程序将首先在$HOME/lib中搜索libtest.so。当然此时它是找不到该文件的。于是根据LD_LIBRARY_PATH的值，动态链接程序将搜索$HOME/sharedlib目录，这时它将找到所需要的库。
此种方法能够奏效是因为libtest.so的路径名在myprog中不是硬编码，所以可以在执行程序时引导动态链接程序搜索另外一个目录。也就是说，可以移动共享库而不致使引用程序无法运行，但是如果在同动态库链接时使用的是硬编码，那么就无法获得此种灵活性了。
硬编码是什么意义呢？这种做法实际上是违反cc命令行用-l指定待链接的库的约定，而直接使用库文件的全路径名进行链接。例如我们可以将myfunc.c作成一个动态链接库：
$ cc -K PIC -G -o $HOME/myfunc myfunc.c
这里生成的动态库的名称是$HOME/myfunc。由于没有遵循对动态库的命名约定，故我们想链接该库时将不能再使用-l选项的方法。而只好使用如下的“硬编码”：
$ cc -o myprog myprog.c $ HOME/myfunc
使用此种方法，编译链接也能够成功，但如果其后我们将myfunc移至另外某个目录下，则除了重新链接myprog之外别无他法。
动态链接的动态特点使得我们可以在不改变函数调用接口的前提下，对共享库的实现进行一定程度的更新，而不用重新对用到的该共享库的程序进行编译、链接。当然在动态链接库被更新之后，需要核实一下使用到该动态库的程序与新版本的兼容性，这个可以使用ldd命令来完成。