如何部署依赖于动态库的应用程序？答案

【问题标题】：How to deploy application that depends on dynamic libraries?如何部署依赖于动态库的应用程序？
【发布时间】：2010-01-22 17:14:51
【问题描述】：

我正在开发一个使用 GStreamer 库的应用程序。为了简化部署，我想在本地包中收集所有 GStreamer 库。为此，我编写了一个小脚本，执行以下操作：

递归遍历依赖（使用otool -L）
将所有依赖项复制到本地目录
使所有依赖路径相对于@executable_path（使用install_name_tool）

（有兴趣的可以看看Ruby script。）

但是，我现在在 gst_init 调用中看到运行时错误：

(process:22843): GLib-GObject-CRITICAL **: gtype.c:2458: initialization assertion failed, use g_type_init() prior to this function

(process:22843): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

仅当我使用本地化库时才会出现这些错误。

在使用 install_name_tool 时是否存在某些“常见陷阱”？有谁知道我做错了什么？如果您需要了解某些细节，请随时询问。

更新
我改变了一些东西：

对于依赖库，我现在只更改 dylib 路径而不更改 id（仅使用 install_name_tool -change 而不是 install_name_tool -id）。
对于主库，我设置了相对于可执行路径 (@executable_name/components/Video.dylib) 的 id 值。

这两个变化使它工作。但是，我还不清楚它为什么起作用。我在理解“id”属性的含义时遇到了一些麻烦。它似乎是路径名形式的标识符。为什么为依赖库更改它会导致运行时错误？我将尝试通过进一步的实验找到这些问题的答案...

【问题讨论】：

会不会是不小心影响了各个依赖的加载顺序？
@gf：我不这么认为，但我会记住的。我已经取得了一些进展，如果您有兴趣，请查看编辑。
你不是在构建一个 .app 包吗？

标签： c++ macos dynamic-linking install-name-tool

【解决方案1】：

也许您应该考虑对代码进行静态编译。这将更好地将您的依赖项附加到您的程序中

如果您使用 gcc，只需添加 -static

【讨论】：

【解决方案2】：

GStreamer 是一个复杂的系统，有很多依赖项。使用工具会找到 GStreamer 直接需要的共享库，但肯定会错过动态加载的库、配置文件以及翻译数据。

This site probably contains some usefull info 关于创建独立的 GStreamer 包，这可以简化捆绑过程。

【讨论】：