应用程序不可避免要使用多个第三方库

开发一个应用程序不可避免要使用多个第三方库(library).
默认情况下，gcc采用动态连接的方式连接第三方库,比如指定-lpng，连接程序就会去找libpng.so。

这个-static选项是个大杀器，指定了这个选项，gcc在连接时对项目所有的依赖库都尝试去搜索名为lib<name>.a的静态库文件，完成静态连接，如果找不到就报错了。这里指的所有是不仅指我们常用的第三方库比如jpeg,png,opencv,zlib,...,还包括gcc编译器自带的库libgcc,libstdc++,libc,libm...，总之就是linux kernal之外的所有库。而且还要包括所有被间接引用的第三方库，比如png这个库在编译时还用到了zlib,那么静态连接png的时候，就要带上zlib的库：-lpng -lz,

这可麻烦大了,要把这些东西全静态连接，这得有多大？呵呵，这事儿我干过，十几兆字节总是有的，取决你的程序用到多少第三方库。
这种全静态连接有啥用处呢？也有用，就是你的程序自带干粮，只需要一个linux kernal就能跑了。

但是实际应用中，我们绝大多数应用场景不需要这么做，即使在嵌入式系统中也不一定必要，尤其是嵌入式系统的存储容量受限，这么一只大象装都装不下。所以我们大多数情况下需要有选择的进行静态编译，-static并不适合。

如何有选择的进行静态编译呢？

最简单的方式直接在连接参数中以全路径指定连接库就好了： your/path/lib<name>.a
但这种形式对管理结构简单而且自己写Makefile的小型项目还好，当一个项目结构复杂，有时需要静态连接有时需要动态连接，这种频繁的修改编译脚本的方式，可维护性就太差了。

-注意上面的说明中红框标注的内容，如果-l:filename格式指定一个文件名，连接程序直接去找这个文件名了，不会再像使用-lname时将name扩展成lib<name>.a格式的文件名.
所以使用 -l:libpng.a这样的形式来指定连接库，就指定了静态连接png库。
当然如果库的位置不在gcc默认搜索路径中，要用-L参数另外指定搜索库的路径，否则连接程序不知道该从哪里找到filename。