最近在遇到一些动态库添加的问题,被折磨了好久,最后发现一篇很好的文章,不过是英文的,翻译一下留着备用。

原文地址

动态库(Unix类似系统中以 .dylib 结尾的文件)不同于静态库(.a结尾),静态库会在代码编译链接后打包进二进制可执行程序。而另一种库是在运行期才会加载,注意这里是加载没有链接的过程。加载意味着程序会在需要的查找该库。这也是为什么会有一些情况,当你很开心的双击打开一个程序却告诉你缺少xx库的原因。(翻译注:用Windows同学很容易碰到缺少 xx.dll, dll 文件类似这里的 dylib 库)。不同的是,静态库会把需要的部分编译进你的app,因此用户不会遇到这么多麻烦。

为什么要使用动态库呢?

是因为文件大小! 静态库要比同等功能的动态库大很多倍,举个例子我们比较一个下 OSX 下的 SDL库,如果你用 homebrew 安装了SDL它的路径在 /usr/local/Cellar/sdl2/2.0.3/lib/

1
2
3
$ ls /usr/local/Cellar/sdl2/2.0.3/lib/ -lh
-r--r--r-- 1 user admin 850K Jul 20 22:18 libSDL2-2.0.0.dylib
-r--r--r-- 1 user admin 1.5M Oct 22 2014 libSDL2.a

有两种方式添加一个第三方动态库到Xcode target:

  1. 安装库到系统
  2. 复制库到product
1 安装库到系统

对于大多数的第三方库可用安装到系统中,路径为 /usr/local/lib 或者 /usr/lib。如果报头文件找不到需要把头文件的路径添加到 Xcode target > Build Setting。最后在 Xcode target -> Build Phase -> Linked Libraries and Frameworks.

但是这种方法并不能方便你的用户使用app,因为需要用户自己安装库文件。对于app来说没有比这更糟糕的。

2 复制 .dylib 到Product

显而易见一个更好的使用动态库的方法应该是把 .dylib 与 app 绑定起来。 让路径相对于自己比相对于系统要好很多。

程序是如何通知系统需要哪些库呢?

由于程序是从一个二进制文件开始运行,那么这个文件是唯一能够通知系统需要哪些库的。从另一个角度来看,这个二进制文件是开发者与用户系统之间的桥梁,编译器和链接器是建造者。因此我们可以通过 OSX提供的otool问问二进制文件。

假设我有一个叫 Vivi 的项目,APP是 Vivi.app,Vivi使用了两个我的库为ViviSwiften.frameworkViviinterface.framework,他们也在 Vivi 项目下,尽管你可以双击运行APP,但是它本身并不是真正的二进制文件。执行的二进制文件在 AppName.app/Contents/MacOS/AppName路径下。

让我们来问一下这个 Vivi 二进制文件

1
2
3
4
5
6
7
8
9
10
11
12
13
$ otool -L Vivi.app/Contents/MacOS/Vivi 
Vivi.app/Contents/MacOS/Vivi:
@rpath/ViviInterface.framework/Versions/A/ViviInterface (compatibility version 1.0.0, current version 1.0.0)
@rpath/ViviSwiften.framework/Versions/A/ViviSwiften (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1223.0.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1387.1.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1225.0.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
@rpath/libswiftAppKit.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libswiftCore.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libswiftCoreData.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libswiftCoreGraphics.dylib (compatibility version 0.0.0, current version 0.0.0)
...

看上去 otool 打印出所有链接的库和他们的版本信息

有很多的内容,你看,我找到了我自己的 framworks, ViviSwiften.frameworkViviInterface.framework。现在我知道了ViviInterface.framework/Versions/A/ViviInterface是二进制程序的framework路径(与 .app不同,framework的二进制文文件位于 FrameworkName.framework/Versions/A/FrameworkName ),但是 @rpath的含义是什么?


@excutable_path @loader_path@rpath的含义是什么?

参考 OS X Man Page:dyld(1)(也可以通过 man dyld),Build Settings中的变量@rpath,@loader_path,@executable_path.

这三个变量的含义如下:

  • @executable_path 总是指向product中的二进制执行文件路径,AppName.app/Contents/MacOS/AppName.
  • @loader_path 与具体的加载的库有关,比如 Vivi.app 加载 ViviSwiften.framwork,那么 @loader_path=/path/to/ViviSwiften.framwork/Versions/A/(翻译注:该变量代表加载的库的二进制的路径,因此不同的库会解析成不同的路径,同样也适用于其他二进制的执行文件)和@"executable_path=/path/to/Vivi.app/Contents/MacOS"
  • @rpath 是预定义的路径,你可以在 Xcode target > Build Setting > Runpath search Path进行设置。对于App target 经常包含 @executable_path/../Frameworks, 对于一个 framework target 常用的有 @executable_path/../Frameworks@loader_path/Frameworks, 对于单元测试一般用@executable_path/../Frameworks@loader_path/../Frameworks

现在我们知道 Vivi.app 使用的是我自己创建 Viviswiften.frameworkViviInterface.framwork 以及一些系统的 framwork 或者 libraries,但是没有第三方的动态库文件。Viviswiften.framework 引用了 libSwiften.3.0.dylib, 让我们来查看一下

1
2
3
4
5
6
$ otool -L ViviSwiften.framework/Versions/A/ViviSwiften
ViviSwiften.framework/Versions/A/ViviSwiften:
@rpath/ViviSwiften.framework/Versions/A/ViviSwiften (compatibility version 1.0.0, current version 1.0.0)
@loader_path/Frameworks/libSwiften.3.0.dylib (compatibility version 3.0.0, current version 3.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57301.0.0)
...

可以看到 ViviSwiften.framwork 用了一个第三方的动态库 libSwiften.dylib,路径是 @loader_path/Frameworks/libSwiften.3.0.dylib

系统是如何找到这些库或者framwork的呢?(以 Vivi 为例)

  1. 用户双击打开 Vivi.app
  2. Vivi.app 执行 Vivi.app/Contents/MacOS/Vivi
  3. 查找 Vivi.app 需要的动态库
  4. 找到 @rpath/ViviSwiften.framework/Versions/A/ViviSwiften, 然后拼成 @executable_path/../Frameworks/..(翻译注:原文这里是@executable_path/../Frameworks/ViviSwiften/,应该是多了一个ViviSwiften),最后拼成Vivi.app/Contents/MacOS/Vivi/../Frameworks/ViviSwiften.framework
  5. 查找 Viviswiften.framwork需要的动态库
  6. 找到 @loader_path/Frameworks/libSwiften.3.0.dylib,然后拼成 ViviSwiften.framework/Version/A/Frameworks/libSwiften.3.0.dylib

这些信息是如何写入二进制执行文件的呢?

我们知道这些信息是在二进制文件中,但是他们是如何写到那里的呢?是两位辛勤的构建者:编译器和链接器。 编译器会把需要的标示符传递给链接器,链接器会负值查找你告诉它需要的标示符,如果你提供的是静态库,链接器会把整个文件写入二进制文件中,如果你提供的是动态库,只有库的路径会写进二进制文件。

链接器是如何找到这些路径的呢?

不幸的是,这个路径并不是APP的开发者提供的,而是由第三方库的开发者提供的。因此你不能够让 Xcode 使用相对于你自己的项目或者自己提供路径。

我们重新看一下 ViviSwiften.framwork:

1
2
3
4
5
$ otool -L ViviSwiften.framework/Versions/A/ViviSwiften
ViviSwiften.framework/Versions/A/ViviSwiften:
@rpath/ViviSwiften.framework/Versions/A/ViviSwiften (compatibility version 1.0.0, current version 1.0.0)
@loader_path/Frameworks/libSwiften.3.0.dylib (compatibility version 3.0.0, current version 3.0.0)
...

我们从第一行可以看到ViviSwiften自己的路径。那就是他的路径。
描述自己的路径变量是 install_name
ViviSwiften.framwork 提供了正确的路径。但是是不是第三方库都会按我们想的那样提供合适的路径呢? 答案是NO。

编译第三方库会提供什么样的路径呢?

有两种方式:

  1. 使用 Homebrew 或者从源码编译如(make install),库的路径会如下:/usr/lib/libxxx.dylib/usr/local/lib/libxx.dylib .
  2. 你也可通过./configure && make编译源代码, 这时候库的路径没有前缀只有 libxx.dylib

但是这两种解决方法都不是我们想要的。

把 install_name 更改成需要的

OS X 提供了另一个工具叫 install_name_tool 来改变 install_name 和链接库的 install_name

1
2
3
4
# change linked lib path
$ install_name_tool -change old new bin_file
# change the library install_name
$ install_name_tool -id new_install_name bin_file 

最终解决策略

作为结论,添加第三方的动态库如下所示:

  1. 添加库到 Build Phase, 添加头文件搜索路径,保证没有编译和链接错误。
  2. 让 Xcode 在编译后复制 .dylib 文件到product下,添加 New Copy Files Phase 并命名为 Copy Libraries

  1. 修改 DestinationFramworks,添加 .dylib文件


4 修改库的 install_name

1
$ install_name_tool -id @loader_path/Frameworks/libSwiften.3.0.dylib libSwiften.3.0.dylib

完毕