编译静态库动态库

A. Android.mk介绍(一)

在linux下，可以通过Makefile来对源码工程进行管理，Android.mk文件是Makefile的一小部分，它用来对Android程序进行编译。Android.mk文件中描述了哪些C文件将被编译且指明了如何编译。Android.mk文件用来告知NDK Build 系统关于Source的信息。

1、编译可执行程序

2、编译动态库或静态库

3、预编译文件(APK或java库)

以上三种是Android.mk的主要用法，我们写mk文件时也就是以上三种目的。

首先看一个最简单的Android.mk的例子：

讲解：

每个Android.mk文件必须以定义 LOCAL_PATH 为开始。它用于在开发tree中查找源文件。

宏 my-dir 由Build System提供。返回包含Android.mk的目录路径。

CLEAR_VARS 变量由Build System提供。并指向一个指定的GNU Makefile，由它负责清理很多LOCAL_xxx.

例如：LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES等等。但不清理 LOCAL_PATH .

这个清理动作是必须的，因为所有的编译控制文件由同一个GNU Make解析和执行，其变量是全局的。所以清理后才能避免相互影响。

LOCAL_MODULE 模块必须定义，以表示Android.mk中的每一个模块。名字必须唯一且不包含空格。

Build System会自动添加适当的前缀和后缀。例如，foo，要产生动态库，则生成libfoo.so.

但请注意：如果模块名被定为：libfoo.则生成libfoo.so. 不再加前缀。

LOCAL_SRC_FILES变量必须包含将要打包如模块的C/C++ 源码。

不必列出头文件，build System 会自动帮我们找出依赖文件。

缺省的C++源码的扩展名为.cpp. 也可以修改，通过LOCAL_CPP_EXTENSION。

BUILD_SHARED_LIBRARY：是Build System提供的一个变量，指向一个GNU Makefile Script。

它负责收集自从上次调用include $(CLEAR_VARS) 后的所有LOCAL_XXX信息。并决定编译为什么。

BUILD_STATIC_LIBRARY：编译为静态库。
BUILD_SHARED_LIBRARY ：编译为动态库
BUILD_EXECUTABLE：编译为Native C可执行程序

BUILD_PACKAGE（既可以编apk，也可以编资源包文件，但是需要指定LOCAL_EXPORT_PACKAGE_RESOURCES:=true)

BUILD_JAVA_LIBRARY（Java共享库）

BUILD_STATIC_JAVA_LIBRARY（java静态库）

Android源码中有大量的mk文件，Android系统的编译就是靠着这些mk文件的，所以学好是非常有必要的哦！

B. 如何生成静态库和动态库

静态库

静态库的后缀是.a，它的产生分两步

Step 1.由源文件编译生成一堆.o，每个.o里都包含这个编译单元的符号表
Step 2.ar命令将很多.o转换成.a，成为静态库
动态库的后缀是.so，它由gcc加特定参数编译产生。具体方法参见后文实例。123123

在 GNU/Linux 系统中静态链接文件实际上就是多个 .o 文件的压缩包。假设我们有 cool.h cool.c 和 some.c 文件，要得到静态链接库 libcool.a。首先使用如下指令得到相应的 object 文件 cool.o 和 some.o：

gcc -c cool.c
gcc -c some.c1212

用这种方法生成的 object 文件称为 PDC 即位置相关代码（position-dependence code）。再使用如下指令可以得到静态链接文件 libcool.a：

ar -r libcool.a cool.o some.o
ranlib libcool.a1212

静态链接库 libcool.a 遵从 GNU/Linux 规定的静态链接库命名规范，必须是”libyour_library_name.a”

动态库

在 GNU/Linux 中动态链接文件，必需通过链接器 ld 生成。假设我们有 hot.c other.c 等文件要生成动态链接库 libhot.so 。首先使用如下指令得到相应的 object 文件 hot.o 和 some.o

gcc -fPIC -c hot.c
gcc -fPIC -c other.c1212

参数 -fPIC 指定生成的 object 文件为位置无关代码（position-independence code），只有 PIC 可以被用作生成动态链接库。然后使用如下指令得到动态库：

ld -Bshared -o libhot.so hot.o other.o11

或者可以使用编译器的ld wrapper：

gcc -shared -o libhot.so hot.o other.o11

也可以使用编译器直接生成动态库：

gcc -fPIC -shared -o libhot.so hot.c other.c11

这里选项 -shared 指示目标文件的类型是动态链接库，动态库的命名规范是”libyour_library_name.so”

C. Makefile.am 规则和实例详解

编写Linux C 程序的时候，自己来写Makefile着实的让人很头疼，如果是简单的项目自己写写也就罢了，但是如果遇到大项目自己写Makefile，那是要弄死人的，所以最近在研究Autotools工具自动生成Makefile，在用到autotools工具生成Makefile的时候，还是有一部分需要自己来完成的，那就是Makefile.am文件。

项目中写在源文件里的Makefile.am是一种比我们了解的Makefile更高层次的编译规则，它可以和编写的configure.in（了解更多configure.in的规则请阅读《 configure.ac (configure.in)详解 》）文件一起通过调用automake命令，来生成Makefile.in文件，然后再调用./configure，将Makefile.in文件自动的生成Makefile文件。所以Makefile.am文件是要自动生成Makefile必不可少的元素，下面鹏博客就来和大家着重的学习下Makefile.am的写法和规则。

先来说下Makefile.am中常见的文件编译类型，详细的编译类型和全局变量鹏博客会在下面在图表中列出：

PROGRAMS           表示可执行文件

SOURCES              表示源文件

HEADERS              头文件。

LIBRARIES             表示库文件

LTLIBRARIES         这也是表示库文件，前面的LT表示libtool。

DATA                       数据文件，不能执行。

SCRIPTS                脚本文件，这个可以被用于执行。如：example_SCRIPTS，如果用这样的话，需要我们自己定义安装目录下的example目录，很容易的，往下看。

一、基本写法

下面就直接引入一个例子进行详细讲解，如下：

AUTOMAKE_OPTIONS = foreign

bin_PROGRAMS = client

client_SOURCES = key.c connect.c client.c main.c session.c hash.c

client_CPPFLAGS = -DCONFIG_DIR=\“$(sysconfdir)\” -DLIBRARY_DIR=\”$(pkglibdir)\”

client_LDFLAGS = -export-dynamic -lmemcached

noinst_HEADERS = client.h

INCLUDES = -I/usr/local/libmemcached/include/

client_LDADD = $(top_builddir)/sx/libsession.la \

$(top_builddir)/util/libutil.la

上面就是一个Makefile.am示例文件，这个文件是用于生成client可执行应用程序，引用了两个静态库和MC等动态库的连接。

先来看个图表一（列出了可执行文件、静态库、头文件和数据文件，四种书写Makefile.am文件个一般格式。）：

对于可执行文件和静态库类型，如果只想编译，不想安装到系统中，可以用noinst_PROGRAMS代替bin_PROGRAMS，noinst_LIBRARIES代替lib_LIBRARIES。以此类推。

根据这个图表一来分析下具体内容：

AUTOMAKE_OPTIONS ：这个是用来设定automake的选项。automake主要是帮助开发GNU软件的人员维护软件套件，一般在执行automake时会检查目录下是否存在标准GNU套件中应具备的文件档案，例如NEWS、AUTHOR、ChangeLog等，设成foreign时，automake会改用一般软件套件标准来检查，而gnu是缺省设置，该级别下将尽可能地检查包是否服从GNU标准，gnits是严格标准，不推荐。

bin_PROGRAMS ：表示要生成的可执行应用程序文件，这里的bin表示可执行文件在安装时需要被安装到系统中，如果只是想编译。不想被安装到系统中，可以用noinst_PROGRAMS来代替。

那么整个第一行 bin_PROGRAMS=client 详细表示什么意思那，解释如下：

PROGRAMS知道这是一个可执行文件。

client表示编译的目标文件。

bin表示目录文件被安装到系统的目录。

如程序和图片所示，包括头文件，静态库的定义等等都是这种形式，如lib_LIBRARIES=util，表示将util库安装到lib目录下。

继续解释文件内容：

client_SOURCES ：表示生成可执行应用程序所用的所有源文件源文件，多个就空格隔开，我们注意到client_是由前面的bin_PROGRAMS指定的，如果前面是生成example, 那么这里也就变成example_SOURCES，其它的规则类似标识也是一样。

client_CPPFLAGS ：这个和我们写Makefile的时候意思是一样的，都表示C语言的预处理器参数，这里指定了DCONFIG_DIR，以后在程序中，就可以直接使用CONFIG_DIR,不要把这个和另一个CFLAGS混淆，后者表示编译器参数。

client_LDFLAGS ：表示在连接时所需要的库文件选项标识。这个也就是对应一些如-l,-shared等选项。

noinst_HEADERS ：表示该头文件只是参加可执行文件的编译，而不用安装到安装目录下。如果需要安装到系统中，可以用include_HEADERS来代替。

INCLUDES ：表示连接时所需要的头文件。

client_LDADD ：表示连接时所需要的库文件,这里表示需要两个库文件的支持，下面会看到这个库文件又是怎么用Makefile.am文件后成的。

如图表二：

全局变量 ，可能有人注意到文件中的$(top_builddir)等全局变量，其实这个是Makefile.am系统定义的一个基本路径变量，表示生成目标文件的最上层目录，如果这个Makefile.am文件变成其它的Makefile.am文件，那么这个就表示其它的目录，而不是这个当前目录。我们还可以使用$(top_srcdir)，这个表示工程的最顶层目录，其实也是第一个Makefile.am的入口目录，因为Makefile.am文件可以被递归性的调用。

如图表三：（在Makefile.am中尽量使用相对路径，系统预定义了两个基本路径）

$(sysconfdir) ：在系统安装工具的时候，我们经常能遇到配置安装路径的命令，如：./configure –prefix=/install/apache  其实在调用这个之后，就定义了一个变量$(prefix), 表示安装的路径，如果没有指定安装的路径，会被安装到默认的路径，一般都是/usr/local。在定义$(prefix)，还有一些预定义好的目录,其实这一些定义都可以在顶层的Makefile文件中可以看到，如下面一些值：

bindir = $(prefix)/bin。

libdir = $(prefix)/lib。

datadir=$(prefix)/share。

sysconfdir=$(prefix)/etc。

includedir=$(prefix)/include。

这些量还可以用于定义其它目录，例如我想 将client.h安装到include/client目录下 ，这样写Makefile.am文件：

clientincludedir=$(includedir)/client

clientinclude_HEADERS=$(top_srcdir)/client/client.h

这就达到了我的目的，相当于定义了一个安装类型，这种安装类型是将文件安装到include/client目录下。

我们自己也可以 定义新的安装目录下的路径 ，如我在应用中简单定义的：

devicedir = ${prefix}/device

device_DATA = package

这样的话，package文件会作为数据文件安装到device目录之下，这样一个可执行文件就定义好了。注意，这也相当于定义了一种安装类型：devicedir，所以你想怎么安装就怎么安装，后面的XXXXXdir，dir是固定不变的。

二、配置静态库

下面我们来说下编译静态库和编译动态库，我们说下静态库，下面这个例子比较简单。直接指定 XXXX_LTLIBRARIES或者XXXX_LIBRARIES就可以了。同样如果不需要安装到系统，将XXXX换成noinst就可以。

一般推荐使用libtool库编译目标，因为automake包含libtool，这对于跨平台可移植的库来说，是一个很好的事情。

看例子如下：

noinst_LTLIBRARIES = libutil.la

oinst_HEADERS = inaddr.h util.h compat.h pool.h xhash.h url.h device.h

ibutil_la_SOURCES = access.c config.c datetime.c hex.c inaddr.c log.c device.c pool.c rate.c sha1.c stanza.c str.c xhash.c

ibutil_la_LIBADD = @LDFLAGS@

第一行的noinst_LTLIBRARIES，这里要注意的是LTLIBRARIES，另外还有LIBRARIES，两个都表示库文件。前者表示libtool库，用法上基本是一样的。如果需要安装到系统中的话，用lib_LTLIBRARIES。

.la 为libtool自动生成的一些共享库，vi编辑查看，主要记录了一些配置信息。可以用如下命令查看*.la文件的格式   $file *.la

.a 为静态库,是好多个.o合在一起,用于静态连接

如果想编译 .a 文件，那么上面的配置就改成如下结果：

noinst_LTLIBRARIES = libutil.a

oinst_HEADERS = inaddr.h util.h compat.h pool.h xhash.h url.h device.h

ibutil_a_SOURCES = access.c config.c datetime.c hex.c inaddr.c log.c device.c pool.c rate.c sha1.c stanza.c str.c xhash.c

ibutil_a_LIBADD = @LDFLAGS@

注意：静态库编译连接时需要其它的库的话，采用XXXX_LIBADD选项，而不是前面的XXXX_LDADD。编译静态库是比较简单的，因为直接可以指定其类型。

三、配置动态库

如果想要编译XXX.so动态库文件，需要用到_PROGRAMS类型，有一个关于安装路径的问题，如果希望将动态库安装到lib目录下，按照前面所说的，只需要写成lib_PROGRAMS就可以了，lib表示安装的路径，但是automake不允许这样直接定义，所以可以采用下面的办法，同样是将动态库安装到lib目录下：

projectlibdir=$(libdir)//新建一个目录，就是该目录就是lib目录

projectlib_PROGRAMS=project.so

project_so_SOURCES=xxx.C

project_so_LDFLAGS=-shared -fpic//GCC编译动态库的选项

这个动态库的编译写法是鹏博客网上总结的，希望有要的人自己来验证下。

四、SUBDIRS功能用法

SUBDIRS 这是一个很重要的词，我们前面生成了一个目标文件，但是一个大型的工程项目是由许多个可执行文件和库文件组成，也就是包含多个目录，每个目录下都有用于生成该目录下的目标文件的Makefile.am文件，但顶层目录是如何调用，才能使下面各个目录分别生成自己的目标文件呢？就是SUBDIRS关键词的用法了。

看一下我的工程项目，这是顶层的Makefile.am文件

EXTRA_DIST = Doxyfile.in README.win32 README.protocol contrib UPGRADE

devicedir = ${prefix}/device

device_DATA = package

SUBDIRS = etc man

ifUSE_LIBSUBST

SUBDIRS += subst

endif

SUBDIRS += tools io sessions util client dispatch server hash storage sms

SUBDIRS表示在处理目录之前，要递归处理哪些子目录，要注意处理的顺序。比如配置中的client对sessions和utils这两上目标文件有依赖关系，就在client之前需要处理这两个目标文件。

EXTRA_DIST ：将哪些文件一起打包。

五、打包处理

Automake会自动的打包 ，自动打包的内容如下：

所有程序的源文件。

所有子目录里的的Makefile.am文件。

Makefile.am中包含的文件。

./configure所要读取的文件。

EXTRA_DIST所指定的文件。

dist和nodist指定的文件，也可将其中一个源文件指定为不打包：

例如： nodist_client_SOURCES = client.c

六、最后

这里是鹏博客总结的一些比较实用的Makefile.am的写法和规则，看完了这篇文章已经可以很详细的理解这个文件的内容，写起来也应该不会陌生，但automake还有许多其他的规则需要掌握，鹏博客将会继续全面的总结关于autotools 的一些规则和写法，希望对大家有用处。也欢迎大家指出问题，帮我完善这个博客，希望大家支持！

automake的Makefile.am Makefile.am写法

D. 如何编译生成和调用静态库

如何编译动态库
gcc test1.c test2.c -shared -fPIC -o libtest.so
使用动态库
gcc main.c -L. -ltest -o a.out
(
-L : 表示需要库的路径
-l：表示需要库的名称，如libtest.so，名称则为test
)
（ps：执行a.out时有可能提示找不到libtest.so文件，这时需要把库文件放入到/lib等目录下，或者添加环境变量LD_LIBRARY_PATH，包含有库文件的路径即可）

如何编译静态库
gcc -c test1.c test2.c
ar -r libtest.a test1.o test2.o
使用静态库
gcc main.c -static -L. -ltest -o a.out
（
-static：可强制编译时使用静态库，如果不使用这个参数，而静态库与动态库同名的话，会优先使用动态库

E. 什么叫静态库和动态库

两者区别：
一，静态库的使用需要：
1
包含一个对应的头文件告知编译器lib文件里面的具体内容
2
设置lib文件允许编译器去查找已经编译好的二进制代码
二，动态库的使用：
程序运行时需要加载动态库，对动态库有依赖性，需要手动加入动态库
三，依赖性：
静态链接表示静态性，在编译链接之后，
lib库中需要的资源已经在可执行程序中了，
也就是静态存在，没有依赖性了
动态，就是实时性，在运行的时候载入需要的资源，那么必须在运行的时候提供
需要的
动态库，有依赖性，
运行时候没有找到库就不能运行了
四，区别：
简单讲，静态库就是直接将需要的代码连接进可执行程序；动态库就是在需要调用其中的函数时，根据函数映射表找到该函数然后调入堆栈执行。
做成静态库可执行文件本身比较大，但不必附带动态库
做成动态库可执行文件本身比较小，但需要附带动态库
五：
首先纠正所谓“静态连接就是把需要的库函数放进你的exe之中”的说法。在真实世界中，有三个概念：use
static
libary,
static
linked
dll,
dynamic
linked
dll.
多数人混淆了static
libary
和
static
linked
dll的概念，当然他们有似是而非的“相似之处”，比如都用到.lib，下面具体说明。
使用静态库(use
static
libary)是把.lib和其他.obj一起build在目标文件中，目标文件可以是.exe,也可以是.dll或.oxc等。一般情况下，可以根本就没有“对应的”.dll
文件，如c
run
time(crt)库。一个例子就是，写一个main(){}，build出来并不是只有几个字节，当然有人会说那还有exe文件头呢？是，即使加上文件头的尺寸，build出的执行文件仍然“莫名的大”。实际上那多出来的部分就是crt静态库。姑且可以把静态库.lib理解成外部程序的obj文件比较合理，它包含了函数的实现。

F. linux 静态库和动态库编译的区别

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

动态库和静态库的区别：
当要使用静态的程序库时，连接器会找出程序所需的函数，然后将它们拷贝到执行文件，由于这种拷贝是完整的，所以一旦连接成功，静态程序库也就不再需要了。然而，对动态库而言，就不是这样。动态库会在执行程序内留下一个标记‘指明当程序执行时，首先必须载入这个库。由于动态库节省空间，linux下进行连接的缺省操作是首先连接动态库，也就是说，如果同时存在静态和动态库，不特别指定的话，将与动态库相连接。

两种库的编译产生方法：
第一步要把源代码编绎成目标代码。以下面的代码hello.c为例，生成hello库：

/* hello.c */
#include
void sayhello()
{
printf("hello,world\n");
}
用gcc编绎该文件，在编绎时可以使用任何全法的编绎参数，例如-g加入调试代码等：
gcc -c hello.c -o hello.o
1.连接成静态库
连接成静态库使用ar命令，其实ar是archive的意思
$ar cqs libhello.a hello.o
2.连接成动态库
生成动态库用gcc来完成，由于可能存在多个版本，因此通常指定版本号：
$gcc -shared -Wl,-soname,libhello.so.1 -o libhello.so.1.0 hello.o
另外再建立两个符号连接：
$ln -s libhello.so.1.0 libhello.so.1
$ln -s libhello.so.1 libhello.so
这样一个libhello的动态连接库就生成了。最重要的是传gcc -shared 参数使其生成是动态库而不是普通执行程序。
-Wl 表示后面的参数也就是-soname,libhello.so.1直接传给连接器ld进行处理。实际上，每一个库都有一个soname，当连接器发现它正在查找的程序库中有这样一个名称，连接器便会将soname嵌入连结中的二进制文件内，而不是它正在运行的实际文件名，在程序执行期间，程序会查找拥有 soname名字的文件，%B

G. ubuntu+cmake+opencv 静态库编译和使用

https://opencv.org/releases/page/2/

能看到其中一个很明显的改变就是“BUILD_SHARED_LIBS=NO”这个选项，代表了不编译动态库，而是编译静态库。后面那些则是增加一些opencv所依赖的第三方库，也要把他们一起生成才行。

参考连接： https://blog.csdn.net/woainishifu/article/details/79712110

缺少：libwebp.a

缺少：libIlmImf.a

缺少：liblibjasper.a

缺少：libittnotify.a

先完整编译opencv 环境 

https://www.jianshu.com/p/f73fcb9a0b1a

再使用 locate 查找 .a静态文件

H. 如何将第三方类库编译自己的动态库文件中

随着动态库的流行，静态库越来越少了（关于动态库和静态库的介绍请点击），但是不排除项目中有些依赖的第三方还是使用的静态库。

那么这种情况下就可以考虑，将第三方静态库做一个二次封装。一来和业务代码进行隔离，方便以后第三方库的升级，二来将静态库封装进动态库里便于管理和利用动态库的优势。一般情况下，用动态库封装静态库很简单，就是将静态库直接拖进动态库的工程里，直接编译即可。但是有一种情况下这么做是不行的，需要暴露静态库的头文件，也就是虽然静态库放在动态库里面了，但是静态库的头文件还要提供给上层应用调用。