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

一尘不染

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

linux

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

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

我应该在这里静态链接以避免LD_LIBRARY_PATH吗？我在LD_LIBRARY_PATH上看到有冲突的报告；像教程这一个建议是“正确的方式”来修改库路径通过系统重新启动，以使用共享库。
其他人
 建议我永远不要设置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吗？我是否应该包括所需的特定版本的库，然后弄清楚如何使可执行文件在这些库的本地目录中显示，而忽略在库路径中找到的可执行文件？

阅读 290

2020-06-03

共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开发人员不喜欢它，他们不关心是否支持它，并且他们设法在每个发行版中都将其破解得更加困难。

祝好运。

2020-06-03