la文件和libtool
Linux下文件的类型是不依赖于其后缀名的，但一般来讲：
??? .o,是目标文件,相当于windows中的.obj文件
??? .so 为共享库,是shared object,用于动态连接的,和dll差不多
??? .a为静态库,是好多个.o合在一起,用于静态连接
??? .la为libtool自动生成的一些共享库，vi编辑查看，主要记录了一些配置信息。可以用如下命令查看*.la文件的格式?? $file *.la
1 libtool的工作原理?
libtool 是一个通用库支持脚本，将使用动态库的复杂性隐藏在统一、可移植的接口中；使用libtool的标准方法，可以在不同平台上创建并调用动态库。可以认为libtool是gcc的一个抽象，其包装了gcc（或者其他的编译器），用户无需知道细节，只要告诉libtool需要编译哪些库即可，libtool将处理库的依赖等细节。libtool只与后缀名为lo、la为的libtool文件打交道。?
libtool主要的一个作用是在编译大型软件的过程中解决了库的依赖问题；将繁重的库依赖关系的维护工作承担下来，从而释放了程序员的人力资源。libtool提供统一的接口，隐藏了不同平台间库的名称的差异等细节，生成一个抽象的后缀名为la高层库libxx.la（其实是个文本文件），并将该库对其它库的依赖关系，都写在该la的文件中。该文件中的dependency_libs记录该库依赖的所有库（其中有些是以.la文件的形式加入的）；libdir则指出了库的安装位置；library_names记录了共享库的名字；old_library记录了静态库的名字。?
当编译过程到link阶段的时候，如果有下面的命令：?
$libtool --mode=link gcc -o myprog -rpath /usr/lib –L/usr/lib –la?
libtool会到/usr/lib路径下去寻找liba.la，然后从中读取实际的共享库的名字（library_names中记录了该名字，比如liba.so）和路径(lib_dir中记录了，比如libdir=’/usr/lib’)，返回诸如/usr/lib/liba.so的参数给激发出的gcc命令行。?
如果liba.so依赖于库/usr/lib/libb.so，则在liba.la中将会有dependency_libs=’-L/usr/lib -lb’或者dependency_libs=’/usr/lib/libb.la’的行，如果是前者，其将直接把“-L/usr/lib –lb”当作参数传给gcc命令行；如果是后者，libtool将从/usr/lib/libb.la中读取实际的libb.so的库名称和路径，然后组合成参数“/usr/lib/libb.so”传递给gcc命令行。?
当要生成的文件是诸如libmylib.la的时候，比如：?
$libtool --mode=link gcc -o libmylib.la -rpath /usr/lib –L/usr/lib –la?
其依赖的库的搜索基本类似，只是在这个时候会根据相应的规则生成相应的共享库和静态库。?
注意：(1)libtool在链接的时候只会涉及到后缀名为la的libtool文件；实际的库文件名称和库安装路径以及依赖关系是从该文件中读取的。?
(2)并不是所有的库都是用libtool编译的。?
?
