1、当静态库和动态库同名时， gcc命令将优先使用动态库。

2、-static 指明链接静态库

3、特别的"-WI，-Bstatic"参数，实际上是传给了连接器ld。指示它与静态库连接，如果系统中 只有静态库当然就不需要这个参数了。 如果要和多个库相连接，而每个库的连接方式不一样，比如上面的程序既要和libhello进行静态连接，又要和libbye进行动态连接，其命令应为：
$gcc testlib.o -o testlib -WI,-Bstatic -lhello -WI,-Bdynamic -lbye

4、-Wl 表示后面的参数也就是-soname,libhello.so.1直接传给连接器ld进行处理。实 际上，每一个库都有一个soname，当连接器发现它正在查找的程序库中有这样一个名称，连接器便会将soname 嵌入连结中的二进制文件内，而不是它正在运行的实际文件名，在程序执行期间，程序会查找拥有 soname名字的文件，而不是库的文件名，换句话说，soname是库的区分标志。 这样做的目的主要是允许系统中多个版本的库文件共存，习惯上在命名库文件的时候通常与soname相同 libxxxx.so.major.minor 其中，xxxx是库的名字，major是主版本号，minor 是次版本号

5、版本编号、soname与 符号连结
每一个程序库都有一个soname。 当连结器发现它正在搜寻的程序库中有这样的一个名称，连结器便会将soname箝入连结中的二进位档内，而不是它正在运作的实际的文件名。在程序执行期间，动态载入 程序会搜寻拥有soname这 样的文件名的文件，而不是程序库的文件名。因此，一个名为libfoo.so的程序库，就可以有一个libbar.so的soname了。 而且所有连结到libbar.so的程序，当程序开始执行时，会寻找的便是libbar.so了。
这听起来好像一点意义也没有，但是这一点，对于了解数个不同版本的同一个程序库是如何在单一系统上共存的原因，却是关键之钥。Linux程序库标准的命名 方式，比如说是libfoo.so.1.2，而且给这个程序库一个libfoo.so.1的soname。 如果此程序库是加到标准程序库的目录底下 （e.g. /usr/lib），ldconfig会建立符号连结libfoo.so.1 -> libfoo.so.1.2，使其正确的image能於执行期间找到。你也需要连结libfoo.so -> libfoo.so.1，使ld能於连结期间找到正确的soname。
所以罗，当你修正程序库内的bugs，或是添加了新的函数进去（任何不会对现存的程序造成不利的影响的改变），你会重建此程序库，保留原本已有的soname，然 后更改程序库文件名。当你对程序库的变更会使得现有的程序中断，那么你只需增加soname中的编号---此例中，称新版本为 libfoo.so.2.0，而soname变成libfoo.so.2。紧接著，再将libfoo.so的连结转向新的版本；至此，世界又再度恢复了和平！
其实你不须要以此种方式来替程序库命名，不过这的确是个好的传统。ELF赋予你在程序库命名上的弹性，会使得人气喘呼呼的搞不清楚状况；有这样的弹性在， 也并不表示你就得去用它。
ELF总结：假设经由你睿智的观察发现有个惯例说：程序库主要的升级会破坏兼容性；而次要的升级则可能不会；那么以下面的方式来连结，所有的一切就都会相 安无事了。
gcc -shared -Wl,-soname,libfoo.so.major -o libfoo.so.major.minor

6、共享库的一个非常重要的，也是非常难的概念是 soname--简写共享目标名（short for shared object name）。这是一个为共享库（.so）文件而内嵌在控制数据中的名字。如前面提到的，每一个程序都有一个需要使用的库的清单。这个清单的内容是一系列库 的 soname， 如同 ldd 显示的那样，共享库装载器必须找到这个清单。
soname 的关键功能是它提供了兼容性的标准。当要升级系统中的一个库时，并且新库的 soname 和老的库的 soname 一样，用旧库连接生成的程序，使用新的库依然能正常运行。这个特性使得在 Linux 下，升级使用共享库的程序和定位错误变得十分容易。
在 Linux 中，应用程序通过使用 soname，来指定所希望库的版本。库作者也可以通过保留或者改变      soname 来声明，哪些版本是相互兼容的，这使得程序员摆脱了共享库版本冲突问题