大家好！我来自南京，在OpenHarmony成长计划啃论文俱乐部，与华为、软通动力、润和软件、拓维信息、深开鸿等公司一起，学习和研究操作系统技术，从今年1月11日加入OpenHarmony俱乐部已经有接近8个月时间了。笔者一直在思考啃论文给我带来了些什么，通过啃论文能为OpenHarmony做些什么。笔者利用大二升大三暑假两个月时间移植了Speexdsp这个三方库到OpenHarmony标准系统，而关于前面的问题我似乎找到了答案，现将啃论文和三方库移植分享经验如下：
在linux上生成speexdsp的so动态链接库和.a静态链接库。
make和make install后会生成speexdsp的.so动态链接库和.a静态链接库。
make
make install
其中build/lib目录下：
├── libspeexdsp.a /*静态库*/
├── libspeexdsp.la /*记录同名动态库和静态库相关信息的la文本文件*/
├── libspeexdsp.so -> libspeexdsp.so.1.5.2
├── libspeexdsp.so.1 -> libspeexdsp.so.1.5.2 /*符号链接*/
├── libspeexdsp.so.1.5.2 /*动态库*/
└── pkgconfig /*pkgconfig 的 *.pc文件*/
└── speexdsp.pc
linux下的so、o、lo、a、la文件
- o: 编译的目标文件。
- a: 静态库，其实就是把若干o文件打了个包。
- so: 动态链接库（共享库） 动态库文件必须以lib开头,以.so结尾。
- lo: 使用libtool编译出的目标文件，其实就是在o文件中添加了一些信息。
- la: 使用libtool编译出的库文件，其实是个文本文件，记录同名动态库和静态库的相关信息。
知识拓展：
- 函数库分为静态库*a和动态库*.so两种：
①静态库在程序编译时会被连接到目标代码中，程序运行时将不再需要该静态库。
②动态库在程序编译时并不会被连接到目标代码中，而是在程序运行是才被载入，因此在程序运行时还需要动态库存在。
- 符号链接（symbolic link）是 Linux 系统中的一种文件，它指向系统中的另一个文件或目录。符号链接类似于 Windows 系统中的快捷方式。
- 在linux中，*.la是记录同名动态库和静态库相关信息的文本文件。
三、分析speexdsp在标准Linux系统的编译过程文件
分析speexdsp在标准Linux系统的编译过程文件，找到生成so库和测试用的可执行文件所需的.c源代码，头文件路径，cflags编译器标志，所依赖的库。
对比编译前后的speexdsp原生库结构
- tree工具能以树形的方式显示指定目录的层级结构。
非绿色字体是编译后生成的文件。
├──
├──#speexdsp项目作者信息
├──#autogen.sh脚本配置文件
├── aclocal.m4 #运行aclocal后生成的aclocal.m4文件和一个缓冲文件夹autom4te.cache
├── autom4te.cache
│ ├── output.0
│ ├── output.1
│ ├── output.2
│ ├── requests
│ ├── traces.0
│ ├── traces.1
│ └── traces.2
├── build
│ ├── include
│ │ └── speex
│ │ ├── speexdsp_config_types.h
│ │ ├── speexdsp_types.h
│ │ ├── speex_echo.h
│ │ ├── speex_jitter.h
│ │ ├── speex_preprocess.h
│ │ └── speex_resampler.h
│ ├── lib
│ │ ├── libspeexdsp.a
│ │ ├── libspeexdsp.la
│ │ ├── libspeexdsp.so -> libspeexdsp.so.1.5.2
│ │ ├── libspeexdsp.so.1 -> libspeexdsp.so.1.5.2
│ │ ├── libspeexdsp.so.1.5.2
│ │ └── pkgconfig
│ │ └── speexdsp.pc
│ └── share
│ └── doc
│ └── speexdsp
│ └── manual.pdf
├──#spexxds原生库更新日志（和本次移植无关信息）
├──
├──#这个是在构建环境上运行的一个脚本，它用来猜测构建机的配置环境，因为这个脚本是在构建机上运行，所以它可以动态执行uname等命令来获得构建机的环境，所以我们一般不要指定这个变量，从而让脚本自动获得。
├── config.h#Config.h是自动生成的头文件，是根据配置文件Config.h.in生成的。config.h主要用于代码移植，产生可移植代码。
├── config.h.in#autoheader后形成config.h.in
├── config.log#该文件在执行configure文件时动态生成，包含了一些行号信息，表示一个文件在哪一行执行，以及执行的什么命令，因此可以知道测试是在哪个位置中完成。
├──#这是脚本文件，运行该脚本可以生成一个当前相同的配置，从而避免再次执行configure这个比较庞大的代码。也就是config.log生成的是文本文件，而config.status生成的则是命令脚本文件。
├──#这个是将host target build变量正则化的一个脚本，它的sub就是substitute的缩写。因为用户提供的build可能并不符合脚本正规的四元组或者三元组的结构，所以这个脚本将它转换为标准的格式，从而可以进行格式化处理。
├──#这个是我们需要监测环境的主要入口文件，使用该文件可以生成Makefile文件，它会替换Makefile中需要替换的变量。
├──#该文件为autoconfigure文件使用的一个文件，该文件用来生成configure文件，这个文件一般是开发者维护，我们安装该软件的时候只需要执行configure就可以，这个configure.ac我们一般不用理会
├──
├──#automake --add-missing命令生成install-sh, missing, depcomp文件
├──
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ ├── Makefile
│ ├──
│ ├── Makefile.in
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ └──
├──
├──
│ ├──
│ ├──
│ └──
├──
│ ├── Makefile
│ ├──
│ ├── Makefile.in
│ └──
│ ├── Makefile
│ ├──
│ ├── Makefile.in
│ ├──
│ ├── speexdsp_config_types.h
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ └──
├──
├──#automake --add-missing命令生成install-sh, missing, depcomp文件
├──
│ ├──
│ ├──
│ ├──
│ ├── buffer.lo
│ ├── buffer.o
│ ├──
│ ├──
│ ├──
│ ├── fftwrap.lo
│ ├── fftwrap.o
│ ├──
│ ├──
│ ├── filterbank.lo
│ ├── filterbank.o
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ ├── jitter.lo
│ ├── jitter.o
│ ├──
│ ├──
│ ├──
│ ├──
│ ├──
│ ├── libspeexdsp.la
│ ├── Makefile
│ ├──
│ ├── Makefile.in
│ ├──
│ ├──
│ ├── mdf.lo
│ ├── mdf.o
│ ├──
│ ├──
│ ├──
│ ├── preprocess.lo
│ ├── preprocess.o
│ ├──
│ ├──
│ ├── resample.lo
│ ├──
│ ├── resample.o
│ ├──
│ ├──
│ ├── scal.lo
│ ├── scal.o
│ ├──
