linux - 部署依赖于共享库的 Linux 应用程序的公认方法是什么？

Question

我有一个依赖于 Qt 的应用程序，GDCM , 和 VTK ，主要构建环境是 Qt。所有这些库都是跨平台的，可以在 Windows、Mac 和 Linux 上编译。在 Windows 上部署后，我需要将应用程序部署到 Linux。我使用的 vtk 和 gdcm 版本是 git 的主干版本(大约一个月前)，比我在 Ubuntu 11.04 上获得的 apt-get 版本更新，Ubuntu 11.04 是我当前(也是唯一的)Linux 部署目标。

部署依赖于此类库的应用程序的公认方法是什么？

我应该在这里静态链接，以避免 LD_LIBRARY_PATH 吗？我在 LD_LIBRARY_PATH 上看到相互矛盾的报告；类似 this one 的教程建议通过系统重新启动修改库路径以使用共享库是“正确的方法”。 Others suggest我永远不应该设置 LD_LIBRARY_PATH。在 GDCM 的默认版本中，安装已经将库放入 /usr/local/lib目录，所以当我运行 ldd <my program> 时可以看到这些库.另一方面，VTK 将其库放入 /usr/local/lib/vtk-5.9 ，它不是大多数用户机器上 LD_LIBRARY_PATH 的一部分，因此除非对系统进行某些更改，否则找不到。将 VTK 文件复制到“/usr/local/lib”不允许“ldd”查看这些文件。

那么，我怎样才能让我的应用程序看到 VTK 以使用这些库？

在 Windows 上，部署 dll 非常简单，因为我可以将它们包含在安装程序中，应用程序会找到它们，因为它们位于本地目录中。这种方法在 Linux 中不起作用，所以我打算让用户从任何合适的来源安装 Qt、GDCM 和 VTK，并使用默认位置，然后让应用程序指向这些默认位置。但是，由于 VTK 将东西放在非标准位置，我是否也应该期望用户修改 LD_LIBRARY_PATH？我是否应该包括我想要的库的特定版本，然后弄清楚如何使可执行文件在本地目录中查找这些库并忽略它在库路径中找到的库？

Answer 1

我见过的每个“严肃的”商业应用程序都使用 LD_LIBRARY_PATH。它们总是包含一个看起来像这样的 shell 脚本:

#!/bin/sh

here="${0%/*}"  # or you can use `dirname "$0"`

LD_LIBRARY_PATH="$here"/lib:"$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH
exec "$0".bin "$@"

他们将此脚本命名为 .wrapper 并创建如下所示的目录树:

.wrapper
lib/  (directory full of .so files)
app1 -> .wrapper (symlink)
app1.bin (executable)
app2 -> .wrapper (symlink)
app2.bin (executable)

现在你可以将整棵树复制到你想要的任何地方，你可以运行“/path/to/tree/app1”或“/path/to/tree/app2 --with --some --arguments”和它会起作用。所以将/path/to/tree 放在你的 PATH 中。

顺便说一句，Firefox 和 Chrome 或多或少也是这样做的。

谁告诉你不要使用 LD_LIBRARY_PATH 的，恕我直言。

要在lib 中放入哪些系统库，取决于您希望正式支持哪些Linux 版本。

甚至不要考虑静态链接。 glibc 开发人员不喜欢它，他们不关心支持它，并且他们设法在每个版本中以某种方式更难地破坏它。

祝你好运。