动态库依赖编译链接

‘壹’ 动态库编译详解

当前类介绍:upper.c ( upper) 依赖于 bottom.c(play)

说明:当执行可执行程序的时候,需要去/lib. /user/lib下和LD_LIBRARY_PATH下寻找so.并不会在当前目录下寻找.

所以执行./main.out会报错.如下:

解决方案:指定.so运行搜寻路径

1.-Wl,-rpath ./mypath 加入参数,并且将libplay.so 到./mypath目录下.

2.设置LD_LIBRARY_PATH,指定目录.

说明:指定了-Wl,-rpath, 设置LD_LIBRARY_PATH也是可以生效的.并不是说只会去-Wl,-rpath下寻找.

首先生成一个bottom.so,然后用upper.so去依赖bottom.so, 然后main.c 再去依赖upper.so.

说明:这里编译的时候直接出错,是因为没有指定搜寻路径,所以无法通过编译.

解决编译问题方案.

1.我们依然采用LD_LIBRARY_PATH的方式可以解决编译和运行的问题.

2.生成libplay的时候,直接指定-Wl,-rpath 给libbottom.可以解决编译不通过的问题.

3.依赖所有库

依赖所有库只能解决编译问题,无法处理运行的路径.

另一种思路:我们在执行main.out的时候 执行-Wl,-rpath.并不在生成libplay的时候指定,看下是否正常.

由此可见,-Wl,-rpath 只能针对直接依赖的libplay.so指定了路径,但是libbottom还是无法查找到 .但是LD_LIBRARY是可以的.

rpath只能对直接依赖的so设置搜寻目录,并且可以设置所有依赖的编译路径.

总结: 解决编译问题,在生成libplay的时候指定-Wl,-rpath运行路径,或者设置LD_LIBRARAY_PATH,都可以解决这个问题.

当我们现在拥有的so包含一个直接依赖的so和很多间接依赖的so,但是没有设置rpath.所以是不能直接依赖主so进行编译和运行的.

为了通过编译:

1.在只链接主so的情况下可以去设置rpath或者LD_LIBRARY_PATH.

2.或者链接所有so.

为了通过运行:

为了正常运行可以设置LD_LIBRARY_PATH.

--disable-new-dtags,---dt-needed-entries

结论概述:

1.我们在生成间接依赖的库的时候,为了保证其他库可以直接依赖,需要加入-Wl,-rpath.保证编译通过.

2.LD_LIBRARY_PATH可以解决一切编译运行问题.

‘贰’ 求助，依赖的动态库包含静态库，编译报错说找

动态链接库和静态链接库一般是编译集成一系列的接口（函数）
在程序源代码编译完成后通过编译器编译并通过链接器与这些库进行链接
动态链接库与静态链接库的区别在于链接器在进行链接时静态库会被直接编译进程序里
而动态链接库并不会，我们这里将这些链接库称作依赖（动态库和静态库）
程序的运行需要这些依赖，程序在静态链接后该程序本身便已包含该依赖
而动态链接后的程序本身本不包含该依赖，这些依赖需要执行者自行安装进操作系统（动态库、运行时库）
程序运行时会动态地加载这些库

linux上动态库一般的后缀后为.so
静态库一般的后缀为.a
由于静态链接会直接将库编译进程序里所以静态编译后的程序相较于动态链接所要大
这就是因为静态链接会将链接库编译进程序里的原因，所以占用就要大了
出于这种原因，静态库不易于维护与更新，如果链接库中有实现有bug等需要更新则需要更新整个程序，因为静态库被编译进程序中了
但动态库就没有这种情况了，因为动态库是程序运行时动态加载的，所以我们只需要更新动态库而不需要更新所有依赖该库的程序（软件）

另一方面，很多程序的开发都会使用到相同的链接库，也就是很多程序（软件）会有相同的依赖
如果将这些依赖全部静态编译的话将会造成存储资源占用过多而造成资源浪费
而使用动态库的方式这些程序（软件）则可以共享一个链接库，而不需要每个程序都带一个链接库，这样就大大地减少了存储资源占用空间

‘叁’ Linux下fortran编译链接

so文件是动态库的集合，由f90文件编译而成，此时f90程序中一般不包含program开头的主程序，而只包含mole，例如：

将f90源文件编译为动态库时，使用命令

此时将生成两个文件，分别为bisectmod.mod和lib***.so，这儿的***是刚才自定义的名字，而*.mod文件名则是f90文件中mole的名字，是自动生成的，如果一个f90文件中包含N个mole，则会生成N个*.mod和1个lib***.so。so文件作为库文件，也可以由多个f90文件共同编译得到，相当于静态库中的打包，将多个库打包到一个里，如下：

动态库的使用包含两部分，一是在编译时，二是在程序运行时。
编译包含动态库的主程序时，要同时制定mod文件的路径和so文件的路径，如果mod文件、so文件以及主程序文件在同一目录下，直接指定so文件即可：

但是当使用第三方库时，通常会分别存放在include和lib文件夹中，此时就要单独指定路径了：

第一个参数-I是大写的i，代表include，第二个l是小写的L，代表lib的名字，可以省略lib以及后面的.so，第三个-L则是lib.so文件的路径。

这样编译的结果不能运行，因为运行时程序找不到lib***.so文件，最好的办法是指定LD_LIBRARY_PATH环境变量，当然也可以将lib***.so文件复制到系统的lib文件夹中。

‘肆’ C语言编辑编译连接的作用是什么

C语言编辑的作用是检查语法，制作C语言的源文件和头文件，生成汇编代码。

C语言编辑的作用是将汇编代码转换机器码。在这一步中，会对文件内部的语法语义做处理，如果编译出错，无法进行后续动作。

C语言链接的作用是将机器码链接到一起生成可执行程序。这一步会对文件之间的关联做检查，如果出错，将不会生成可执行程序，也就无法执行。

(4)动态库依赖编译链接扩展阅读：

C语言链接时，将源文件中用到的库函数与汇编生成的目标文件.o合并生成可执行文件。该可执行文件会变大很多，一般是调用自己电脑上的静态库。

静态库和应用程序编译在一起，在任何情况下都能运行，而动态库是动态链接，文件生效时才会调用。很多代码编译通过，链接失败就极有可能在静态库和动态库这出现了纰漏，要视情况解决。缺少相关所需文件，就会链接报错。这个时候就要检查下本地的链接库是不是缺损。

‘伍’ ndk-Android NDk 怎么编译时动态链接第三方so库，有头文件

问题描述：Android如何调用第三方SO库；
已知条件：SO库为Android版本连接库（*.so文件），并提供了详细的接口说明；
已了解解决方案：
1.将SO文件直接放到libs/armeabi下，然后代码中System.loadLibrary("xxx")；再public native static int xxx_xxx_xxx()；接下来就可以直接调用xxx_xxx_xxx()方法；
2.第二种方案，创建自己的SO文件，在自己的SO文件里调用第三方SO，再在程序中调用自己的SO，这种比较复杂，需要建java类文件，生成.h文件，编写C源文件include之前生成的.h文件并实现相应方法，最后用android NDK开发包中的ndk-build脚本生成对应的.so共享库；
求解：
1.上面两种方案是否可行？不可行的话存在什么问题？
2.两种方案有什么区别？为什么网上大部都是用的第二种方案？
3.只有一个*.so文件，并提供了详细的接口说明，是否可在ANDROID中使用它？

首先要看这个SO是不是JNI规范的SO，比如有没有返回JNI不直接支持的类型。也就是说这个SO是不是可以直接当作JNI来调用。如果答案是否定的，你只能选第二个方案。

如果答案是肯定的，还要看你是不是希望这个SO的库直接暴露给JAVA层，如果答案是否定的，你只能选第二个方案，比如你本身也是一个库的提供者。

一般如果你只有SO，就说明这个是别人提供给你的，你可以要求对方给你提供配套的JAVA调用文件。

1、这个要看这个SO是不是符合JNI调用的规范。还要看你自己的意愿。
2、因为第二种方法最灵活，各种情况都可以实现。
3、可以

看能不能直接从JAVA调用的最简单的方法就是看SO里的函数名是不是Java_XXX_XXX_XXX格式的
是就可以，你可以自己写一个配套的JAVA文件，注意一下SO函数名和JAVA函数名的转换规则，或者向SO提供方索要；
不是的话就选第二种方案吧。

1、检查所需文件是否齐全
使用第三方动态库，应该至少有2个文件，一个是动态库（.so），另一个是包含
动态库API声明的头文件(.h)
2、封装原动态库
原动态库文件不包含jni接口需要的信息，所以我们需要对其进行封装，所以我
们的需求是：将libadd.so 里面的API封装成带jni接口的动态
3、编写库的封装函数libaddjni.c
根据前面生成的com_android_libjni_LibJavaHeader.h 文件，编写libaddjni.c，用
来生成libaddjni.so

Android中集成第三方软件包（.jar, .so）

Android中可能会用到第三方的软件包，这包括Java包.jar和Native包.so。jar包既可通过Eclipse开发环境集成，也可通过编译源码集成，看你的工作环境。

假定自己开发的程序为MyMaps，需要用到BaiMaps的库，包括mapapi.jar和libBMapApiEngine_v1_3_1.so。

一、Eclipse中集成第三方jar包及.so动态库

MyMaps工程下创建目录libs以及libs/armeabi，把mapapi.jar放在的libs/目录下，把libBMapApiEngine_v1_3_1.so放在libs/armeabi/下。

Eclipse中把第三方jar包mapapi.jar打包到MyMaps的步骤：

1. 右击工程，选择Properties；
2. Java Build Path，选择Libraries；
3. Libraries页面点击右面按钮“Add Library…”；
4. 选择“User Library”，点击“Next”；
5. 点击“User Libraries”按钮；
6. 在弹出界面中，点击“New…”；
7. 输入“User library name”，点击“OK”确认；
8. 返回之后，选择刚刚创建的User library，右面点击“AddJARs”；
9. 选择MyMaps/libs/下的mapapi.jar；
10. 确认，返回。

这样，编译之后，该jar包就会被打进MyMaps.apk中，libBMapApiEngine_v1_3_1.so也被打包在lib/armeabi/中。
程序运行过程中，libBMapApiEngine_v1_3_1.so被放在/data/data/<yourAppPackage>/lib/下，加载动态库时系统会从程序的该lib/目录下查找.so库。

二、源码中集成第三方集成jar包及.so动态库

Android源码中MyMaps放在packages/apps下。MyMaps下创建目录libs以及libs/armeabi，并把mapapi.jar放在libs/，把libBMapApiEngine_v1_3_1.so放在libs/armeabi。

2.1 修改Android.mk文件

Android.mk文件如下：

[plain] view plain
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE_TAGS := optional

LOCAL_STATIC_JAVA_LIBRARIES := libmapapi

LOCAL_SRC_FILES := $(call all-subdir-java-files)

LOCAL_PACKAGE_NAME := MyMaps

include $(BUILD_PACKAGE)

##################################################
include $(CLEAR_VARS)

LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES :=libmapapi:libs/mapapi.jar
LOCAL_PREBUILT_LIBS :=libBMapApiEngine_v1_3_1:libs/armeabi/libBMapApiEngine_v1_3_1.so
LOCAL_MODULE_TAGS := optional
include $(BUILD_MULTI_PREBUILT)

# Use the following include to make our testapk.
include $(callall-makefiles-under,$(LOCAL_PATH))

1 集成jar包
LOCAL_STATIC_JAVA_LIBRARIES取jar库的别名，可以任意取值；
LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES指定prebuiltjar库的规则，格式：别名:jar文件路径。注意：别名一定要与LOCAL_STATIC_JAVA_LIBRARIES里所取的别名一致，且不含.jar；jar文件路径一定要是真实的存放第三方jar包的路径。
编译用BUILD_MULTI_PREBUILT。
2 集成.so动态库
LOCAL_PREBUILT_LIBS指定prebuilt so的规则，格式：别名:so文件路径。注意：别名一般不可改变，特别是第三方jar包使用.so库的情况，且不含.so；so文件路径一定要是真实的存放第三方so文件的路径。
编译拷贝用BUILD_MULTI_PREBUILT。

2.2 加入到GRANDFATHERED_USER_MODULES

在文件user_tags.mk中，把libBMapApiEngine_v1_3_1加入到GRANDFATHERED_USER_MODULES中

[plain] view plain
GRANDFATHERED_USER_MODULES += \
… \
libBMapApiEngine_v1_3_1

user_tags.mk可以是build/core下的，也可以是$(TARGET_DEVICE_DIR)下的，推荐修改$(TARGET_DEVICE_DIR)下的。

2.3 编译结果

MyMaps.apk编译生成在out/target/proct/<YourProct>/system/app/下；
libBMapApiEngine_v1_3_1.so放在out/target/proct/<YourProct>/system/lib/下，这也是系统加载动态库时搜索的路径。

‘陆’ g++ 编译命令中依赖的动态库如果还依赖别的库，命令怎么设置

第一步，我先从简单的调用出发，定义了一个简单的函数，该函数仅仅实现一个整数加法求和：

LIBEXPORT_API int mySum(int a,int b){ return a+b;}
C# 导入定义：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Auto,CallingConvention=CallingConvention.StdCall)]
public static extern int mySum (int a,int b);
}
在C#中调用测试：

int iSum = RefComm.mySum(,);

运行查看结果iSum为5，调用正确。第一步试验完成，说明在C#中能够调用自定义的动态链接库函数。

第二步，我定义了字符串操作的函数（简单起见，还是采用前面的函数名），返回结果为字符串：

LIBEXPORT_API char *mySum(char *a,char *b){sprintf(b,"%s",a); return a;}
C# 导入定义：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Auto,
CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, string b);
}
在C#中调用测试：

string strDest="";
string strTmp= RefComm.mySum("45", strDest);

运行查看结果 strTmp 为"45"，但是strDest为空。我修改动态链接库实现，返回结果为串b：

LIBEXPORT_API char *mySum(char *a,char *b){sprintf(b,"%s",a) return b;}
修改 C# 导入定义，将串b修改为ref方式：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Auto,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, ref string b);
}
在C#中再调用测试：

string strDest="";
string strTmp= RefComm.mySum("45", ref strDest);
运行查看结果 strTmp 和 strDest 均不对，含不可见字符。再修改 C# 导入定义，将CharSet从Auto修改为Ansi：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, string b);
}
在C#中再调用测试：

string strDest="";
string strTmp= RefComm. mySum("45", ref strDest);
运行查看结果 strTmp 为"45"，但是串 strDest 没有赋值。第二步实现函数返回串，但是在函数出口参数中没能进行输出。再次修改 C# 导入定义，将串b修改为引用（ref）：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, ref string b);
}

运行时调用失败，不能继续执行。

第三步，修改动态链接库实现，将b修改为双重指针：

LIBEXPORT_API char *mySum(char *a,char **b){sprintf((*b),"%s",a); return *b;}
C#导入定义：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern string mySum (string a, ref string b);
}
在C#中调用测试：

string strDest="";
string strTmp= RefComm. mySum("45", ref strDest);

运行查看结果 strTmp 和 strDest 均为"45"，调用正确。第三步实现了函数出口参数正确输出结果。

第四步，修改动态链接库实现，实现整数参数的输出：

LIBEXPORT_API int mySum(int a,int b,int *c){ *c=a+b; return *c;}
C#导入的定义：

public class RefComm
{
[DllImport("LibEncrypt.dll",
EntryPoint=" mySum ",
CharSet=CharSet.Ansi,CallingConvention=CallingConvention.StdCall)]
public static extern int mySum (int a, int b,ref int c);
}
在C#中调用测试：

int c=0;
int iSum= RefComm. mySum(,, ref c);

运行查看结果iSum 和c均为5，调用正确。

经过以上几个步骤的试验，基本掌握了如何定义动态库函数以及如何在 C# 定义导入，有此基础，很快我实现了变长加密函数在 C# 中的调用，至此目标实现。

三、结论

在 C# 中调用 C++ 编写的动态链接库函数，如果需要出口参数输出，则需要使用指针，对于字符串，则需要使用双重指针，对于 C# 的导入定义，则需要使用引用（ref）定义。

对于函数返回值，C# 导入定义和 C++ 动态库函数声明定义需要保持一致，否则会出现函数调用失败。定义导入时，一定注意 CharSet 和 CallingConvention 参数，否则导致调用失败或结果异常。运行时，动态链接库放在 C# 程序的目录下即可，我这里是一个 C# 的动态链接库，两个动态链接库就在同一个目录下运行。

‘柒’ 面试 | Linux 下的动态链接库问题

在 Linux 开发时，我们经常会看到一些形如 xxx.so 的名称出现，其中 so 是 Shared Object 的缩写，即可以共享的目标文件，也就是我们所称为的动态链接库，和在 Windows 下大家玩 游戏 时遇到的 xxx.dll 错误中的文件是一个类型的。

面试中经常会问到以下问题：

库是写好的现有的，成熟的，可以复用的代码。现实中每个程序都要依赖很多基础的底层库，不可能每个人的代码都从零开始，因此库的存在意义非同寻常。本质上来说库是一种可执行代码的二进制形式，可以被操作系统载入内存执行。

库有两种：

在一个程序的编译过程中，分为以下几个步骤： 预处理 ， 编译 ， 汇编 ， 链接 。本文中讨论的链接库就是针对最后一个步骤“链接”而言的。

动态库和静态库的区别

左图为静态链接库，右图为动态链接库

对于静态链接库而言在链接阶段，会将汇编生成的“目标文件.o”与引用到的库一起链接打包到可执行文件中。因此对应的链接方式称为静态链接：

静态链接可以理解为最后生成了一个“单文件免安装绿色版”的程序，优点在于移植的时候只需要移动这一个文件，缺点在于文件体积非常大，为了解决这样的问题，就有了动态链接库。动态链接库在程序编译时并不会被连接到目标代码中，而是在程序运行时才被载入。

动态库连接到系统空间，如果多个程序连接了同一个库，那么只需要一份，优点在于编译程序的时候不会将对应的库文件全部打包在生成的程序中，而是保留了到对应库的链接，缺点就是移植的时候如果只移动了对应的程序没有安装相关的库的话，就会看到类似以下喜闻乐见的结果了。

在 Linux 下一个动态库有y三个不同名字的文件组成：

当程序在内部列出所需要的链接库时，仅仅使用 soname。当你创建一个链接库时，使用 real name。安装一个新的链接库时，把它复制到一个DLL文件夹里，然后运行程序 ldconfig。ldconfig 检查存在的 real name 文件，并且创建指向它符号链接 soname 文件。可能大家比较常见到的有 libsodium 等。

有了上面关于库的一些基础知识之后，我们可以开始尝试创建一个动态库来供程序使用了。

比如我们有一个求最大值的函数 max(int a,int b,int c) ，放在文件 max.c 中文件内容如下：

可以通过：

将其编译为共享库，-fPIC是编译选项，PIC是 Position Independent Code 的缩写，表示要生成位置无关的代码，这是动态库需要的特性； -shared是链接选项，告诉 gcc 生成动态库而不是可执行文件。为了让用户知道我们的动态库中有哪些接口可用，我们需要编写对应的头文件，比如可以写一个 max.h ：

设置一个驱动函数来测试我们编写的动态库：

通过 gcc test.c -L. -lmax来生成 a.out，其中-lmax表示要链接 libmax.so，-L.表示搜索要链接的库文件时包含当前路径。

但是这样直接运行的话，会出现一个错误：

由于 Linux 是通过/etc/ld.so.cache文件搜寻要链接的动态库的，而 /etc/ld.so.cache 是 ldconfig 程序读取 /etc/ld.so.conf 文件生成的，本次使用的动态库 libmax.so 并不在对应的目录下，就会导致程序无法找到对应的动态链接库，这样我们的解决方法有二：

小结

​动态链接库是各个系统中的一个重要的组成部分且在 Linux 开发相关领域中尤为重要，也是一个面试的高频考点，除了动态链接库以外，还有以下相关知识也是高频考点，在面试前一定要准备好：

本文作者：Nova Kwok

‘捌’ Linux动态库多重依赖，编译问题！！！！！！

这只能说明一个问题，你依赖的库本隐基销身有问题，没有把它的依锋档赖都加进去，也就是你例子中的①灶游libb.so依赖liba.so;，你应该在生成libb.so的时候，把对liba.so的依赖加进去，这样应该就没有问题了。