① 如何使用lame源代码在编译生成linux环境下的动态库
动态库的生成
1>首先生成目标文件，但是此时要加编译器选项-fpic和链接器选项-shared，
gcc -fpic -c add.c
gcc -fpic -c sub.c
生成中间文件add.o和sub.o
2>其次生成动态库
gcc -shared –o libtiger.so add.o sub.o
生成动态库libtiger.so,libtiger.so就是我们生成的目标动态库。我们以后使用动态库和main.c程序生成可执行程序
说明：
以上两部也可以合成一步搞定:
gcc -fpic -shared add.c sub.c -o libtiger.so
2.使用动态链接库
在编译程序时，使用动态链接库和静态库是一致的，使用”-l库名”的方式，在生成可执行文件的时候会链接库文件。
1>使用命令：
gcc -o main main.c -L ./ -ltiger
2>-L指定动态链接库的路劲，-ldtiger链接库函数tiger。-ltiger是动态库的调用规则。Linux系统下的动态库命名方式是lib*.so,而在链接时表示位-l*,*是自己命名的库名。
3>但是程序会提示如下错误
error while loading shared libraries: libtiger.so: cannot open shared object file: No such file or direct
这是因为程序运行时没有找到动态链接库造成的。程序编译时链接动态库和运行时使用动态链接库的概念是不同的，在运行时，程序链接的动态链接库需要在系统目录下才行。
4>使用以下方法可以解决此问题
a. 在linux下最方便的解决方案是拷贝libtiger.so到绝对目录 /lib 下(但是,要是超级用户才可以，因此要使用sudo哦，亲)。就可以生成可执行程序了
b.第二种方法是：将动态链接库的目录放到程序搜索路径中，可以将库的路径加到环境变量LD_LIBRARY_PATH中实现：
export LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH
② 关于linux下连接动态库问题
gcc编译时，当使用动态库编译可以按照几种写法
1.gcc test.c ./libSDL2-2.so
2.gcc test.c -lSDL2-2
3.gcc test.c -L/home/test -lSDL2-2
一般的编译参数都是按照2或3去写
2写法的含义是从/lib或者/usr/lib目录下寻找名称为SDL2-2的库，即寻找/lib/libSDL2-2.so或者/usr/lib/libSDL2-2.so文件进行链接，当然如果没有动态库就会去找静态库，再没有应该就会在编译时报错
3写法的含义是从-L参数首先从指定的目录中寻找需要链接的库文件，随后再去寻找系统文件夹中是否存在需要的库
1写法的含义是将当前目录下的./libSDL2-2.so.0文件链接进最终文件，因此执行readelf -a a.out后在动态库部分所看到的路径就是./libSDL2-2.so.0，进而在执行文件时仅会从当前目录下寻找libSDL2-2.so.0文件，当执行文件时所在的目录下没有该文件时就会出现找不到库文件的操作
你第二次操作时，因为function.so库文件与a.out文件在同一个目录，同时也是在该目录下执行的ldd操作及运行a.out，a.out在加载动态库时从当前目录下找到了所需要的库文件，此时能够执行成功（ldd命令实质是一个脚本，通过设置环境变量运行动态库链接器来输出所有待链接的动态库）。
你可以试试将a.out拷贝至其他目录再次运行，将出现和第一次操作时一样的现象，找不到function.so文件。
具体的解决方法就是修改编译参数，将./libSDL2-2.so.0修改为-lSDL2-2并将libSDL2-2.so.0文件拷贝至/usr/lib目录下，并且可能因为没有修改链接器的缓存文件（将可能找不到带版本号后缀的动态库），需要在/usr/lib目录下建立一个文件连接（ln -s libSDL2-2.so.0 libSDL2-2.so）或者直接修改名称为libSDL2-2.so
③ gcc 生成动态库时-fpic选项是什么意思。
fpic：产生位置无关码
解释一下，位置无关码就是可以在进程的任意内存位置执行的目标码，动态链接库必须使用。
④ 动态库编译详解
当前类介绍:upper.c ( upper) 依赖于 bottom.c(play)
说明:当执行可执行程序的时候,需要去/lib. /user/lib下和LD_LIBRARY_PATH下寻找so.并不会在当前目录下寻找.
所以执行./main.out会报错.如下:
解决方案:指定.so运行搜寻路径
1.-Wl,-rpath ./mypath 加入参数,并且将libplay.so 到./mypath目录下.
2.设置LD_LIBRARY_PATH,指定目录.
说明:指定了-Wl,-rpath, 设置LD_LIBRARY_PATH也是可以生效的.并不是说只会去-Wl,-rpath下寻找.
首先生成一个bottom.so,然后用upper.so去依赖bottom.so, 然后main.c 再去依赖upper.so.
说明:这里编译的时候直接出错,是因为没有指定搜寻路径,所以无法通过编译.
解决编译问题方案.
1.我们依然采用LD_LIBRARY_PATH的方式可以解决编译和运行的问题.
2.生成libplay的时候,直接指定-Wl,-rpath 给libbottom.可以解决编译不通过的问题.
3.依赖所有库
依赖所有库只能解决编译问题,无法处理运行的路径.
另一种思路:我们在执行main.out的时候 执行-Wl,-rpath.并不在生成libplay的时候指定,看下是否正常.
由此可见,-Wl,-rpath 只能针对直接依赖的libplay.so指定了路径,但是libbottom还是无法查找到 .但是LD_LIBRARY是可以的.
rpath只能对直接依赖的so设置搜寻目录,并且可以设置所有依赖的编译路径.
总结: 解决编译问题,在生成libplay的时候指定-Wl,-rpath运行路径,或者设置LD_LIBRARAY_PATH,都可以解决这个问题.
当我们现在拥有的so包含一个直接依赖的so和很多间接依赖的so,但是没有设置rpath.所以是不能直接依赖主so进行编译和运行的.
为了通过编译:
1.在只链接主so的情况下可以去设置rpath或者LD_LIBRARY_PATH.
2.或者链接所有so.
为了通过运行:
为了正常运行可以设置LD_LIBRARY_PATH.
--disable-new-dtags,---dt-needed-entries
结论概述:
1.我们在生成间接依赖的库的时候,为了保证其他库可以直接依赖,需要加入-Wl,-rpath.保证编译通过.
2.LD_LIBRARY_PATH可以解决一切编译运行问题.