查看动态库so命令

adb logcat -s AndroidRuntime

 adb shell nm -D /system/lib/libqcomfm_jni | grep "android_hardware_fmradio_FmReceiverJNI_acquireFdNative"

adb shell nm -D /system/lib/libqcomfm_jni.so

 adb pull /system/lib/libqcomfm_jni.so

nm -D libqcomfm_jni.so

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

linux下查看动态库和静态库

静态库用ar -t YourFile

动态库用 nm -D YourFile

下面是ar和nm命令的一些参数说明

1.ar基本用法

　　ar命令可以用来创建、修改库，也可以从库中提出单个模块。库是一单独的文件，里面包含了按照特定的结构组织起来的其它的一些文件（称做此库文件的member）。原始文件的内容、模式、时间戳、属主、组等属性都保留在库文件中。

　　下面是ar命令的格式：

　　ar [-]{dmpqrtx}[abcfilNoPsSuvV] [membername] [count] archive files...

　　例如我们可以用ar rv libtest.a hello.o hello1.o来生成一个库，库名字是test，链接时可以用-ltest链接。该库中存放了两个模块hello.o和hello1.o。选项前可以有 ‘-‘字符，也可以没有。下面我们来看看命令的操作选项和任选项。现在我们把{dmpqrtx}部分称为操作选项，而[abcfilNoPsSuvV]部 分称为任选项。

　　{dmpqrtx}中的操作选项在命令中只能并且必须使用其中一个，它们的含义如下：

d：从库中删除模块。按模块原来的文件名指定要删除的模块。如果使用了任选项v则列出被删除的每个模块。 
m：该操作是在一个库中移动成员。当库中如果有若干模块有相同的符号定义(如函数定义)，则成员的位置顺序很重要。如果没有指定任选项，任何指定的成员将移到库的最后。也可以使用'a'，'b'，或'I'任选项移动到指定的位置。 
p：显示库中指定的成员到标准输出。如果指定任选项v，则在输出成员的内容前，将显示成员的名字。如果没有指定成员的名字，所有库中的文件将显示出来。 
q：快速追加。增加新模块到库的结尾处。并不检查是否需要替换。'a'，'b'，或'I'任选项对此操作没有影响，模块总是追加的库的结尾处。如果使用了任选项v则列出每个模块。 这时，库的符号表没有更新，可以用'ar s'或ranlib来更新库的符号表索引。 
r：在库中插入模块(替换)。当插入的模块名已经在库中存在，则替换同名的模块。如果若干模块中有一个模块在库中不存在，ar显示一个错误消息，并不替换其他同名模块。默认的情况下，新的成员增加在库的结尾处，可以使用其他任选项来改变增加的位置。 
t：显示库的模块表清单。一般只显示模块名。 
x：从库中提取一个成员。如果不指定要提取的模块，则提取库中所有的模块。 
　　下面在看看可与操作选项结合使用的任选项：

a：在库的一个已经存在的成员后面增加一个新的文件。如果使用任选项a，则应该为命令行中membername参数指定一个已经存在的成员名。 
b：在库的一个已经存在的成员前面增加一个新的文件。如果使用任选项b，则应该为命令行中membername参数指定一个已经存在的成员名。 
c：创建一个库。不管库是否存在，都将创建。 
f：在库中截短指定的名字。缺省情况下，文件名的长度是不受限制的，可以使用此参数将文件名截短，以保证与其它系统的兼容。 
i：在库的一个已经存在的成员前面增加一个新的文件。如果使用任选项i，则应该为命令行中membername参数指定一个已经存在的成员名(类似任选项b)。 
l：暂未使用 
N：与count参数一起使用，在库中有多个相同的文件名时指定提取或输出的个数。 
o：当提取成员时，保留成员的原始数据。如果不指定该任选项，则提取出的模块的时间将标为提取出的时间。 
P：进行文件名匹配时使用全路径名。ar在创建库时不能使用全路径名（这样的库文件不符合POSIX标准），但是有些工具可以。 
s：写入一个目标文件索引到库中，或者更新一个存在的目标文件索引。甚至对于没有任何变化的库也作该动作。对一个库做ar s等同于对该库做ranlib。 
S：不创建目标文件索引，这在创建较大的库时能加快时间。 
u：一般说来，命令ar r...插入所有列出的文件到库中，如果你只想插入列出文件中那些比库中同名文件新的文件，就可以使用该任选项。该任选项只用于r操作选项。 
v：该选项用来显示执行操作选项的附加信息。 
V：显示ar的版本。 
2.nm基本用法命令

　　nm用来列出目标文件的符号清单。下面是nm命令的格式：

　　nm [-a|--debug-syms] [-g|--extern-only] [-B][-C|--demangle] [-D|--dynamic] [-s|--print-armap][-o|--print-file-name] [-n|--numeric-sort][-p|--no-sort] [-r|--reverse-sort] [--size-sort][-u|--undefined-only] [-l|--line-numbers] [--help][--version] [-t radix|--radix=radix][-P|--portability] [-f format|--format=format][--target=bfdname] [objfile...]

　　如果没有为nm命令指出目标文件，则nm假定目标文件是a.out。下面列出该命令的任选项，大部分支持"-"开头的短格式和"—"开头的长格式。

-A、-o或--print-file-name：在找到的各个符号的名字前加上文件名，而不是在此文件的所有符号前只出现文件名一次。

-a或--debug-syms：显示调试符号。 
-B：等同于--format=bsd，用来兼容MIPS的nm。 
-C或--demangle：将低级符号名解码(demangle)成用户级名字。这样可以使得C++函数名具有可读性。 
-D或--dynamic：显示动态符号。该任选项仅对于动态目标(例如特定类型的共享库)有意义。 
-f format：使用format格式输出。format可以选取bsd、sysv或posix，该选项在GNU的nm中有用。默认为bsd。 
-g或--extern-only：仅显示外部符号。 
-n、-v或--numeric-sort：按符号对应地址的顺序排序，而非按符号名的字符顺序。 
-p或--no-sort：按目标文件中遇到的符号顺序显示，不排序。 
-P或--portability：使用POSIX.2标准输出格式代替默认的输出格式。等同于使用任选项-f posix。 
-s或--print-armap：当列出库中成员的符号时，包含索引。索引的内容包含：哪些模块包含哪些名字的映射。 
-r或--reverse-sort：反转排序的顺序(例如，升序变为降序)。 
--size-sort：按大小排列符号顺序。该大小是按照一个符号的值与它下一个符号的值进行计算的。 
-t radix或--radix=radix：使用radix进制显示符号值。radix只能为"d"表示十进制、"o"表示八进制或"x"表示十六进制。 
--target=bfdname：指定一个目标代码的格式，而非使用系统的默认格式。 
-u或--undefined-only：仅显示没有定义的符号(那些外部符号)。 
-l或--line-numbers：对每个符号，使用调试信息来试图找到文件名和行号。对于已定义的符号，查找符号地址的行号。对于未定义符号，查找指向符号重定位入口的行号。如果可以找到行号信息，显示在符号信息之后。 
-V或--version：显示nm的版本号。 
--help：显示nm的任选项。

http://blog.csdn.net/batoom/article/details/6293627

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

一、基本概念

1.1、什么是库

在 windows 平台和 linux 平台下都大量存在着库。

本质上来说库是 一种可执行代码的二进制形式，可以被操作系统载入内存执行。

由于 windows 和 linux 的平台不同（主要是编译器、汇编器和连接器 的不同），因此二者库的二进制是不兼容的。

本文仅限于介绍 linux 下的库。

 

1.2、 库的种类

linux 下的库有两种：静态库和共享库（动态库）。

二者的不同点在于代码被载入的时刻不同。

静态库的代码在编译过程中已经被载入可执行程序，因此体积较大。

静态用.a为后缀， 例如： libhello.a

共享库(动态库)的代码是在可执行程序运行时才载入内存的，在编译过程中仅简单的引用，因此代码体积较小。

动态通常用.so为后缀， 例如：libhello.so

共享库(动态库)的好处是，不同的应用程序如果调用相同的库，那么在内存里只需要有一份该共享库的实例。

为了在同一系统中使用不同版本的库，可以在库文件名后加上版本号为后缀,例如： libhello.so.1.0,由于程序连接默认以.so为文件后缀名。所以为了使用这些库，通常使用建立符号连接的方式。

ln -s libhello.so.1.0 libhello.so.1 ln -s libhello.so.1 libhello.so

1.3、静态库，动态库文件在linux下是如何生成的：

以下面的代码为例，生成上面用到的hello库：

/* hello.c */  

#include "hello.h"  
void sayhello()  
{      
    printf("hello,world ");  
}
首先用gcc编绎该文件，在编绎时可以使用任何合法的编绎参数，例如-g加入调试代码等：
$gcc -c hello.c -o hello.o
1、生成静态库 生成静态库使用ar工具，其实ar是archive的意思
$ar cqs libhello.a hello.o
2、生成动态库 用gcc来完成，由于可能存在多个版本，因此通常指定版本号：
$gcc -shared -o libhello.so.1.0 hello.o
 
1.4、库文件是如何命名的，有没有什么规范： 
在 linux 下，库文件一般放在/usr/lib和/lib下， 
静态库的名字一般为libxxxx.a，其中 xxxx 是该lib的名称；
动态库的名字一般为libxxxx.so.major.minor，xxxx 是该lib的名称，major是主版本号，minor是副版本号 
 
1.5、可执行程序在执行的时候如何定位共享库(动态库)文件 ：
    当系统加载可执行代码(即库文件)的时候，能够知道其所依赖的库的名字，但是还需要知道绝对路径，此时就需要系统动态载入器 (dynamic linker/loader) 
    对于 elf 格式的可执行程序，是由 ld-linux.so* 来完成的，它先后搜索 elf 文件的 DT_RPATH 段—环境变量LD_LIBRARY_PATH—/etc/ld.so.cache 文件列表— /lib/,/usr/lib 目录找到库文件后将其载入内存
    如： export LD_LIBRARY_PATH=’pwd’ 
    将当前文件目录添加为共享目录 
 
1.6、使用ldd工具，查看可执行程序依赖那些动态库或着动态库依赖于那些动态库：
   ldd 命令可以查看一个可执行程序依赖的共享库， 
    例如 # ldd /bin/lnlibc.so.6 
        => /lib/libc.so.6 (0×40021000)/lib/ld-linux.so.2 
        => /lib/ld- linux.so.2 (0×40000000) 
    可以看到 ln 命令依赖于 libc 库和 ld-linux 库 
 
1.7、使用nm工具，查看静态库和动态库中有那些函数名（T类表示函数是当前库中定义的，U类表示函数是被调用的，在其它库中定义的，W类是当前库中定义，被其它库中的函数覆盖）。：
    有时候可能需要查看一个库中到底有哪些函数，nm工具可以打印出库中的涉及到的所有符号，这里的库既可以是静态的也可以是动态的。
    nm列出的符号有很多， 常见的有三种::
    一种是在库中被调用，但并没有在库中定义(表明需要其他库支持)，用U表示；
    一种是在库中定义的函数，用T表示，这是最常见的；
    另外一种是所 谓的“弱态”符号，它们虽然在库中被定义，但是可能被其他库中的同名符号覆盖，用W表示。
    例如，假设开发者希望知道上文提到的hello库中是否引用了 printf():
    $nm libhello.so | grep printf 
    发现printf是U类符号，说明printf被引用，但是并没有在库中定义。
    由此可以推断，要正常使用hello库，必须有其它库支持，使用ldd工具查看hello依赖于哪些库：
    $ldd hello libc.so.6=>/lib/libc.so.6(0x400la000)  /lib/ld-linux.so.2=>/lib/ld-linux.so.2 (0x40000000)
    从上面的结果可以继续查看printf最终在哪里被定义，有兴趣可以go on
 
1.8、使用ar工具，可以生成静态库，同时可以查看静态库中包含那些.o文件，即有那些源文件构成。
    可以使用 ar -t libname.a 来查看一个静态库由那些.o文件构成。
    可以使用 ar q libname.a xxx1.o  xxx2.o xxx3.o ... xxxn.o 生成静态库
    
 
Linux下进行程序设计时，关于库的使用:
 
一、gcc/g++命令中关于库的参数:
-shared： 该选项指定生成动态连接库（让连接器生成T类型的导出符号表，有时候也生成弱连接W类型的导出符号），不用该标志外部程序无法连接。相当于一个可执行文件
-fPIC：表示编译为位置独立(地址无关)的代码，不用此选项的话，编译后的代码是位置相关的，所以动态载入时，是通过代码拷贝的方式来满足不同进程的需要，而不能达到真正代码段共享的目的。
-L：指定链接库的路径，-L. 表示要连接的库在当前目录中
-ltest：指定链接库的名称为test，编译器查找动态连接库时有隐含的命名规则，即在给出的名字前面加上lib，后面加上.so来确定库的名称
LD_LIBRARY_PATH：这个环境变量指示动态连接器可以装载动态库的路径。
   当然如果有root权限的话，可以修改/etc/ld.so.conf文件，然后调用 /sbin/ldconfig来达到同样的目的，
   不过如果没有root权限，那么只能采用修改LD_LIBRARY_PATH环境变量的方法了。 
调用动态库的时候，有几个问题会经常碰到:
    1、有时，明明已经将库的头文件所在目录 通过 “-I” include进来了，库所在文件通过 “-L”参数引导，并指定了“-l”的库名，但通过ldd命令察看时，就是死活找不到你指定链接的so文件，这时你要作的就是通过修改 LD_LIBRARY_PATH或者/etc/ld.so.conf文件来指定动态库的目录。通常这样做就可以解决库无法链接的问题了。
 
二、静态库链接时搜索路径的顺序： 
   1. ld会去找gcc/g++命令中的参数-L；
   2. 再找gcc的环境变量LIBRARY_PATH,它指定程序静态链接库文件搜索路径；
      export LIBRARY_PATH=$LIBRARY_PATH:data/home/billchen/lib 
   3. 再找默认库目录 /lib  /usr/lib  /usr/local/lib，这是当初compile gcc时写在程序内的。 
   
三、动态链接时、执行时搜索路径顺序: 
    1. 编译目标代码时指定的动态库搜索路径；
    2. 环境变量LD_LIBRARY_PATH指定动态库搜索路径，它指定程序动态链接库文件搜索路径；
      export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:data/home/billchen/lib 
    3. 配置文件/etc/ld.so.conf中指定的动态库搜索路径；
    4. 默认的动态库搜索路径/lib；
    5. 默认的动态库搜索路径/usr/lib。 
 
四、静态库和动态链接库同时存在的问题：
   当一个库同时存在静态库和动态库时，比如libmysqlclient.a和libmysqlclient.so同时存在时：
    在Linux下，动态库和静态库同事存在时，gcc/g++的链接程序，默认链接的动态库。
    可以使用下面的方法，给连接器传递参数，看是否链接动态库还是静态库。
    -WI,-Bstatic -llibname        //指定让gcc/g++链接静态库
    使用:
   gcc/g++ test.c -o test -WI,-Bstatic -llibname
   -WI,-Bdynamic -llibname       //指定让gcc/g++链接动态库
    使用:
   gcc/g++ test.c -o test -WI,-Bdynamic -llibname
   如果要完全静态加在，使用-static参数，即将所有的库以静态的方式链入可执行程序，这样生成的可执行程序，不再依赖任何库，同事出现的问题是，这样编译出来的程序非常大，占用空间。
 
五、有关环境变量： 
    LIBRARY_PATH环境变量：指定程序静态链接库文件搜索路径
    LD_LIBRARY_PATH环境变量：指定程序动态链接库文件搜索路径 
 
六、动态库升级问题：
   在动态链接库升级时，
   不能使用cp newlib.so oldlib.so，这样有可能会使程序core掉；
   而应该使用:
   rm oldlib.so 然后 cp newlib.so oldlib.so
   或者
    mv oldlib.so oldlib.so_bak 然后 cp newlib.so oldlib.so
为什么不能用cp newlib.so oldlib.so ?
在替换so文件时，如果在不停程序的情况下，直接用 cp new.so old.so 的方式替换程序使用的动态库文件会导致正在运行中的程序崩溃。
 
解决方法:
解决的办法是采用“rm＋cp” 或“mv＋cp” 来替代直接“cp” 的操作方法。
linux系统的动态库有两种使用方法：运行时动态链接库，动态加载库并在程序控制之下使用。
 
1、为什么在不停程序的情况下，直接用 cp 命令替换程序使用的 so 文件，会使程序崩溃？
很多同学在工作中遇到过这样一个问题，在替换 so 文件时，如果在不停程序的情况下，直接用cp new.so old.so的方式替换程序使用的动态库文件会导致正在运行中的程序崩溃，退出。
这与 cp 命令的实现有关，cp 并不改变目标文件的 inode，cp 的目标文件会继承被覆盖文件的属性而非源文件。实际上它是这样实现的：
strace cp libnew.so libold.so 2>&1 |grep open.*lib.*.so
open("libnew.so", O_RDONLY|O_LARGEFILE) = 3
open("libold.so", O_WRONLY|O_TRUNC|O_LARGEFILE) = 4
在 cp 使用“O_WRONLY|O_TRUNC” 打开目标文件时，原 so 文件的镜像被意外的破坏了。这样动态链接器 ld.so 不能访问到 so 文件中的函数入口。从而导致 Segmentation fault，程序崩溃。ld.so 加载 so 文件及“再定位”的机制比较复杂。
 
2、怎样在不停止程序的情况下替换so文件，并且保证程序不会崩溃？
答案是采用“rm＋cp” 或“mv＋cp” 来替代直接“cp” 的操作方法。
在用新的so文件 libnew.so 替换旧的so文件 libold.so 时，如果采用如下方法：
rm libold.so //如果内核正在使用libold.so，那么inode节点不会立刻别删除掉。
cp libnew.so libold.so
采用这种方法，目标文件 libold.so 的 inode 其实已经改变了，原来的 libold.so 文件虽然不能用　”ls”查看到，但其 inode 并没有被真正删除，直到内核释放对它的引用。
（即: rm libold.so，此时，如果ld.so正在加在libold.so，内核就在引用libold.so的inode节点，rm libold.so的inode并没有被真正删除，当ld.so对libold.so的引用结束，inode才会真正删除。这样程序就不会崩溃，因为它还在使用旧的libold.so，当下次再使用libold.so时，已经被替换，就会使用新的libold.so）
同理，mv只是改变了文件名，其 inode 不变，新文件使用了新的 inode。这样动态链接器 ld.so 仍然使用原来文件的 inode 访问旧的 so 文件。因而程序依然能正常运行。
(即: mv libold.so ***后，如果程序使用动态库，还是使用旧的inode节点，当下次再使用libold.so时，就会使用新的libold.so)

到这里，为什么直接使用“cp new_exec_file old_exec_file”这样的命令时，系统会禁止这样的操作，并且给出这样的提示“cp: cannot create regular file `old': Text file busy”。这时，我们采用的办法仍然是用“rm+cp”或者“mv+cp”来替代直接“cp”，这跟以上提到的so文件的替换有同样的道理。

但是，为什么系统会阻止 cp 覆盖可执行程序，而不阻止覆盖 so 文件呢？
这是因为 Linux 有个 Demand Paging 机制，所谓“Demand Paging”，简单的说，就是系统为了节约物理内存开销，并不会程序运行时就将所有页（page）都加载到内存中，而只有在系统有访问需求时才将其加载。“Demand Paging”要求正在运行中的程序镜像（注意，并非文件本身）不被意外修改，因此内核在启动程序后会锁定这个程序镜像的 inode。
对于 so 文件，它是靠 ld.so 加载的，而ld.so毕竟也是用户态程序，没有权利去锁定inode，也不应与内核的文件系统底层实现耦合。

http://www.cppblog.com/tqsheng/archive/2013/01/04/196948.html

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------