本文的目的是测试各种类型库的编译后的使用效果，包括库又链接其他库的编译方法，使用方法，依赖性等。
 
太长不看版：请跳至文章最后的总结对比表。
 
一。内容包含：
 
①静态库libbb.a依赖静态库libaa.a的测试；
 
②静态库libbb.a依赖动态库libaa.so的测试；
 
③动态库libbb.so依赖静态库libaa.a的测试；
 
④动态库libbb.so依赖动态库libaa.so的测试；
 
所用到的文件列表：
 
aalib.cpp aalib.h        bblib.cpp bblib.h     main.cpp
 
二。源代码：
 
aalib.h
 
#ifndef AALIB_H
 #define AALIB_H
 #include "stdio.h"
 void helloAA();
 
#endif
 
********分割线**************
 
aalib.cpp
 
#include "aalib.h"
 
void helloAA()
 {
     printf(" lib AAAAAAAAAAAAA\n ");
 }
 
********分割线**************
 
bblib.h
 
#ifndef BBLIB_H
 #define BBLIB_H
 
void helloBB();
 void helloAB();
 
#endif
 
********分割线**************
 
bblib.cpp
 
#include "bblib.h"
 #include "aalib.h"
 
void helloBB()
 {
     printf(" lib BBBBBBBBBBBBBBBB \n");
 }
 
void helloAB()
 {
     printf(" *a*******************\n");
     helloAA();
     helloBB();
     printf(" *b*******************\n");
 }
 
********分割线**************
 
main.cpp
 
#include "bblib.h"
 
int main()
 {
     helloBB();
 
    helloAB();
 }
  
 
三。测试过程
 
①静态库libbb.a依赖静态库libaa.a的测试
 
 
现在生成了静态库libaa.a和libbb.a，下面测试静态库的使用方法：
 
 
可以看到链接静态库的话要指定静态库依赖的静态库，否则编译不过去！由此可见轻易不要链接静态库，因为你也许不知道你要用的静态库还依赖着哪些库.......
 
那么将所依赖的静态库编译进静态库呢？试试
 
 
可以看到，使用命令ar rcs libbb.a bblib.o libaa.a并没有起到作用，亦即libaa.a并没有被编译进libbb.a，因此编译可执行程序时还需要链接libaa.a。
 
改用下面这种方式编译，可行：
 
 
即编译静态库libbb.a时不要链接libaa.a而是用aalib.o文件，亦即编译静态库链接静态库时不能直接链接静态库，而是用形成该静态库的那些.o文件，可以使用 ar -x libaa.a来获取静态库的所有.o文件（注意：所有.o文件的顺序要对，被依赖的要放后面）。
 
②静态库libbb.a依赖动态库libaa.so的测试
 
 
第一行命令：gcc -o libaa.so -shared -fPIC aalib.cpp
 
等价于：gcc -c -shared -fPIC aalib.cpp 加 gcc -o libaa.so -shared -fPIC aalib.o 这两条（注意编译.o时要加选项-shared -fPIC，否则无法生存.so）
 
可以看到，编译可执行程序时只链接静态库不链接动态库编译不过去！运行时也需要动态库libaa.so支持
 
那么将动态库编译进静态库中呢？试试
 
 
可以看到，虽然编译静态库libbb.a的时候链接了动态库libaa.so，编译可执行程序只链接静态库libbb.a也能编译过去，但是在执行时还是要libaa.so动态库支持。
 
③动态库libbb.so依赖静态库libaa.a的测试
 
 
可以看到编译libbb.so时链接静态库出错，提示静态库需要使用-fPIC选项来编译，那就按照提示的来修改编译命令：
 
 
静态库所需的.o文件使用-shared -fPIC编译，然后在编译动态库的时候链接静态库好用了。并且编译可执行文件时不用链接被依赖的静态库。
 
来看一下这个动态库libbb.so依赖哪些库：
 
 
可以看到没有依赖libaa.a这个静态库。
 
④动态库libbb.so依赖动态库libaa.so的测试
 
 
动态库链接动态库成功，并且编译可执行文件时也不用链接被依赖的库，但是运行时还是要两个动态库支持。
 
四。总结
 
被依赖的库aa
编译库aa的命令
直接库bb
编译库bb的命令
编译可执行程序的命令
编译时是否需要库aa
运行时是否需要库aa
libaa.a
 
gcc -c aalib.cpp
 
 ar rcs libaa.a aalib.o
 
libbb.a
gcc -c bblib.cpp                                ar rcs libbb.a bblib.o
gcc -o out main.cpp libbb.a libaa.a
需要
不需要
libaa.a
gcc -c aalib.cpp      ar rcs libaa.a aalib.o
libbb.a
gcc -c bblib.cpp                               ar rcs libbb.a bblib.o aalib.o
gcc -o out main.cpp libbb.a 
不需要
不需要
libaa.so
gcc -o libaa.so -shared -fPIC aalib.cpp
libbb.a
gcc -c bblib.cpp                               ar rcs libbb.a bblib.o libaa.so
gcc -o out main.cpp libbb.a
不需要
需要
libaa.a
gcc -c aalib.cpp      ar rcs libaa.a aalib.o
libbb.so
gcc -o libbb.so -shared -fPIC bblib.cpp libaa.a
编译libbb.so就出错，无法编译成动态库
 
 
libaa.a
gcc -c -shared -fPIC aalib.cpp               ar rcs libaa.a aalib.o
libbb.so
gcc -o libbb.so -shared -fPIC bblib.cpp libaa.a
gcc -o out main.cpp -L./ -lbb
不需要
不需要
libaa.so
gcc -o libaa.so -shared -fPIC aalib.cpp
libbb.so
gcc -o libbb.so -shared -fPIC bblib.cpp -L./ -laa
gcc -o out main.cpp -L./ -lbb
不需要
需要
其他说明：链接静态库时要注意顺序，使用第二行的方法编译直接库libbb.a的时候用到被依赖库的.o文件，注意些个.o文件的依赖顺序也很重要，不能错，被依赖的要放后面。另外：编译好的动态库要指定路径，否则运行时找不到动态库的位置。
 
五。结论
 
    由于本测试的初衷是找出一种方法使得编译可执行程序时不链接那些被依赖的库，因此第二行和第五行的组合可以作为备选方案。

QT下生成动态库并链接
 
请测有效
 
Qt下生成动态库,参考文章: https://www.cnblogs.com/boright88/p/6263137.html
 
Qt下链接动态库,参考文章: https://blog.csdn.net/yanmanm/article/details/82704651
 
1、 qt下生成动态库
 
（1）、新建库。文件à新建文件及项目à库(Library)
 à选择共享库并输入库名称à一直点击下一步直到填写类信息à为类命名à点击完成。
 
（2）、点击项目à取消影子文件的勾。
 
（3）、查看库文件所在目录下是否生成两个.h和一个.cpp文件。
 
（4）、在*.h文件中加入自己的功能函数。
 
（5）、点击构建。
 
（6）、查看库文件所在目录下的debug或release里是否有.dll文件。有则成功生成动态库。
 
2、 qt动态库的链接
 
新建widgets项目.
 
（1）、qt显示调用动态库(较麻烦,lib文件不存在)
 
（2）、qt隐示调用动态库(需要.lib文件的存在)
 
   1、如1.2的方法去掉新建项目的影子目录.

   2、将库文件的.dll .lib .h三个文件拷贝到新建widgets.

   3、对项目点击”添加库”->外部库->并浏览到.lib文件目录点击完成.

   4、初始化库对象实例.并调用方法.

gcc常用编译选项：
 
 
选项
 
含义
-static
链接静态库，禁止使用动态库
-shared
进行动态库编译，链接动态库
-Ldir
在动态库的搜索路径中增加dir目录
-lname
链接静态库(libname.a)或动态库(libname.so)的库文件
-fPIC(或fpic)
生成使用相对地址无关的目标代码
方法一：
 
第一步：使用-shared参数生成动态库，gcc -shared -fPIC -o libtest.so test.c     然后把libtest.so复制到/usr/lib64/系统路径下
 
注意：生成的动态库的名字必须是lib+名字.so，之后可以直接使用-ltest来引用动态库。
 
第二步：编译main.c，使用libtest.so动态库，gcc -o main main.c -L/usr/lib64/ -ltest
 
方法二：
 
在编译main.c，并链接libtest.so的时候，直接指定使用当前目录下的libtest.so文件,
 
使用命令：gcc -o main main.c ./libtest.so

1 前言
 
这两天在编写一个插件系统Demo的时候，发现了个很奇怪的问题：插件加载器中已经链接了ld库，但是应用程序在链接插件加载器的时候，却还需要显式的来链接ld库。否则就会报：DSO missing from command line。这个报错翻译过来就是没有在命令行中指定该动态库。
 这个报错就很搞事了，你说你明明知道需要哪个库，为什么不直接帮我链接呢，非得我显示的在命令行中指定呢？
 
2 现象描述
 
问题可以简单描述为：当链接可执行文件时，依赖于libA.so，而libA.so又依赖于libB.so，而且可执行文件中还直接调用了libB.so中的函数，那么此时链接就会出现错误。
 
2.1 问题发生的前置条件
 
libA.so在编译过程中显式的链接了libB.so
可执行文件中使用了libB.so的函数
binuntils版本 ≥ 2.22
 
2.2 Talk is cheap. Show me the code
 
话不多说，先看看可以复现改问题的代码吧
 
libB.so的源码：
 
#include <stdio.h>

int funB1(){

    printf("in funB1");

    return 0;
}

int funB2(){

    printf("in funB2");

    return 0;
}

 
这里面有两个函数：funB1和funB2。
 其中funB1函数会被libA调用，而funB2会被可执行文件调用。
 
编译libB.so:
 
$ gcc libB.cpp -fPIC -shared -o libB.so
 
 
libA.so的源码：
 
#include <stdio.h>

int funB1();

int funA1(){

    printf("in funA1 \n");

    funB1();

    return 0;
}
 
该库中只有一个函数funA1，该函数在内部调用了libB中的funB1函数。且该函数会被可执行文件调用。
 
编译libA.so:
 
$ gcc libA.cpp -fPIC -shared -o libA.so -Wl,-rpath=./ -L./ -lB
 
 
main.cpp的源码：
 
int funA1();
int funB2();

int main(){

    funA1();
    funB2();

    return 0;
}
 
编译main.cpp:(复现错误的编译方法)
 
gcc main.cpp -L./ -lA
 
当我们按照上面的指令编译main.cpp的时候，便报错了。
 
/usr/bin/ld: /tmp/ccDQXTKy.o: undefined reference to symbol '_Z5funB2v'
.//libB.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

 
（问号.jpg）这，这GCC不是搞事吗，你明明知道我需要连接libB.so为啥就不帮我链接上去呢？难道我libA.so没有指明要使用libB.so?我们使用下面的指令来看一下
 
$ ldd libA.so
 
得到如下信息：
 
	linux-vdso.so.1 =>  (0x00007ffd09def000)
	libB.so => ./libB.so (0x00007fc513d7d000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc5139b3000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fc514181000)

 
明明libA.so已经显式的指明我要依赖libB.so了，那为啥在编译main.cpp的时候链接了libA.so，GCC却还要我们显式的链接libB.so呢？
 
3 答案
 
答案很简单，那就是GCC就是想要你显式链接呗。（你是编译器，你牛好吧。）那这是为啥呢？
 官方一点的答案就是，自从binutils 2.22版本以后，如果你在程序中使用了你依赖的动态库所依赖的动态库中的函数时，你就必须显式的指定你依赖的动态库所依赖的动态库。
 
说那么多，我们更想知道的是，通过修改什么参数可以解决这个问题呢？因为你可能不想在编译程序的时候要把动态库所依赖的所有动态库都显示链接一遍。
 
4 究极答案
 
实际上，这是binutils在2.22版本以后，默认把--no-copy-dt-needed-entries这个选项打开了。当打开了这个选项的时候，编译器在链接的时候是不会递归的去获取依赖动态库的依赖项的，于是就会出现上述的问题。关于该配置项的详细说明如下：
 
   --copy-dt-needed-entries
   --no-copy-dt-needed-entries
       This option affects the treatment of dynamic libraries referred to by DT_NEEDED tags inside ELF dynamic libraries mentioned on the command line.  Normally the linker won't add a DT_NEEDED
       tag to the output binary for each library mentioned in a DT_NEEDED tag in an input dynamic library.  With --copy-dt-needed-entries specified on the command line however any dynamic
       libraries that follow it will have their DT_NEEDED entries added.  The default behaviour can be restored with --no-copy-dt-needed-entries.

       This option also has an effect on the resolution of symbols in dynamic libraries.  With --copy-dt-needed-entries dynamic libraries mentioned on the command line will be recursively
       searched, following their DT_NEEDED tags to other libraries, in order to resolve symbols required by the output binary.  With the default setting however the searching of dynamic
       libraries that follow it will stop with the dynamic library itself.  No DT_NEEDED links will be traversed to resolve symbols.
 
大概意思就是，跟在--no-copy-dt-needed-entries它后面的库都不会遍历其依赖项，使用--copy-dt-needed-entries则相反。也就是使用下面的指令来编译mian.cpp就可以避免该问题了。
 
$ gcc main.cpp -L./ -Wl,--copy-dt-needed-entries -lA
 
题外话
 
 
 
在Linux的ELF文件中，如果依赖于其他的动态库，那么改ELF文件会存在一个.dynamic的段，这个段里面会记录其依赖的动态库信息，其标志位为DT_NEEDED。
 
 
5 参考文档
 
1，DSO missing from command line原因及解决办法：https://segmentfault.com/a/1190000002462705
 2，折腾gcc/g++链接时.o文件及库的顺序问题： https://www.cnblogs.com/OCaml/archive/2012/06/18/2554086.html#sec-1-4-1