部署基于共享库的linux应用程序的接受方法是什么？ [英] What's the accepted method for deploying a linux application that relies on shared libraries?

问题描述

我有一个依赖于Qt的应用程序， GDCM 和 VTK ，主要的构建环境是Qt。所有这些库都是跨平台的，并在Windows，Mac和Linux上编译。在Windows上部署后，我需要将应用程序部署到Linux。我使用的vtk和gdcm的版本是来自git（大约一个月大）的trunk版本，比在Ubuntu 11.04中可以得到apt-get更近，这是我当前的（而且只有）Linux部署目标。 p>

部署依赖于这些类库的应用程序的接受方法是什么？

我应该静态链接到这里，以避免LD_LIBRARY_PATH？我看到有关LD_LIBRARY_PATH的冲突报告;诸如这一个的教程表明，修改库路径以使用共享库的正确方法系统重新启动其他 建议，我不应该设置LD_LIBRARY_PATH。在GDCM的默认版本中，安装程序已将库放入 / usr / local / lib 目录中，所以当我运行 ldd时看到这些库<我的程序> 。另一方面，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？我应该包括我想要的库的具体版本，然后弄清楚如何使可执行文件看到这些库的本地目录，并忽略它在库路径中找到的库。

解决方案

我见过的每一个严重商业应用使用 LD_LIBRARY_PATH 。它们总是包含一个看起来像这样的shell脚本：

 ＃！/ bin / sh 
 
这里=$ {0％/ *}＃或者你可以使用`dirname'$ 0`
 
 LD_LIBRARY_PATH =$ here/ lib：$ LD_LIBRARY_PATH
 export LD_LIBRARY_PATH 
 exec$ 0.bin$ @
  

他们将这个脚本命名为 .wrapper 并创建一个目录树，如下所示：

  .wrapper 
 lib /（目录下的.so文件）
 app1  - > .wrapper（symlink）
 app1.bin（可执行文件）
 app2  - > .wrapper（symlink）
 app2.bin（可执行文件）
  

现在你可以复制这个树到任何你想要的，你可以运行/ path / to / tree / app1或/ path / to / tree / app2 --with --some -arguments，它将工作。所以将把/ path / to / tree放在你的PATH中。

顺便提一句，这也是Firefox和Chrome的做法，或多或少。
$ b

谁告诉你不要使用 LD_LIBRARY_PATH 已经满了，IMHO。

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

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

祝你好运。 p>

I have an application that relies on Qt, GDCM, and VTK, with the main build environment being Qt. All of these libraries are cross-platform and compile on Windows, Mac, and Linux. I need to deploy the application to Linux after deploying on Windows. The versions of vtk and gdcm I'm using are trunk versions from git (about a month old), more recent than what I can get apt-get on Ubuntu 11.04, which is my current (and only) Linux deployment target.

What is the accepted method for deploying an application that relies on these kinds of libraries?

Should I be statically linking here, to avoid LD_LIBRARY_PATH? I see conflicting reports on LD_LIBRARY_PATH; tutorials like this one suggest that it's the 'right way' to modify the library path to use shared libraries through system reboots. Others suggest that I should never set LD_LIBRARY_PATH. In the default version of GDCM, the installation already puts libraries into the /usr/local/lib directory, so those libraries get seen when I run ldd <my program>. VTK, on the other hand, puts its libraries into /usr/local/lib/vtk-5.9, which is not part of the LD_LIBRARY_PATH on most user's machines, and so is not found unless some change is made to the system. Copying the VTK files into '/usr/local/lib' does not allow 'ldd' to see the files.

So, how can I make my application see VTK to use the libraries?

On windows, deploying the dlls is very straightforward, because I can just include them in the installer, and the application finds them because they are in the local directory. That approach does not work in Linux, so I was going to have the users install Qt, GDCM, and VTK from whatever appropriate source and use the default locations, and then have the application point to those default locations. However, since VTK is putting things into a non-standard location, should I also expect users to modify LD_LIBRARY_PATH? Should I include the specific versions of the libraries that I want and then figure out how to make the executable look in the local directory for those libraries and ignore the ones it finds in the library path?

解决方案

Every "serious" commercial application I have ever seen uses LD_LIBRARY_PATH. They invariably include a shell script that looks something like this:

#!/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 "$@"

They name this script something like .wrapper and create a directory tree that looks like this:

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

Now you can copy this whole tree to wherever you want, and you can run "/path/to/tree/app1" or "/path/to/tree/app2 --with --some --arguments" and it will work. So will putting /path/to/tree in your PATH.

Incidentally, this is also how Firefox and Chrome do it, more or less.

Whoever told you not to use LD_LIBRARY_PATH is full of it, IMHO.

Which system libraries you want to put in lib depends on which Linux versions you want to officially support.

Do not even think about static linking. The glibc developers do not like it, they do not care about supporting it, and they somehow manage to break it a little harder with every release.

Good luck.

这篇关于部署基于共享库的linux应用程序的接受方法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！