处理Linux上的库依赖关系 [英] Dealing with library dependencies on linux
问题描述
我在项目中使用libcurl，它在运行时依赖于openssl和其他.so.
这种依赖性有点麻烦，因为不同的发行版/版本可能包含不同的openssl版本.
I am using libcurl in my project and it depends on openssl and bunch of other .so in runtime.
This dependency is kind of pain in the ass, since different distributives/versions may contain different openssl versions.
例如，如果我在Ubuntu 9.10上编译应用程序，则遇到在Ubuntu 11.10上运行的问题.
For example I am experiencing problems running on Ubuntu 11.10 if I compiled my app on Ubuntu 9.10.
我看到了两种解决方案，但是对于我的情况来说，它们都不足够:
I am seeing two options how to solve this but none of them aren't good enough for my case:
-
打包我的应用，然后让打包管理器解决这类问题
package my app and let package manager solve this sort of stuff
静态链接所有部门
我的应用程序确实很小，并且打包/维护它可能会过大.另外，要求之一是它应可下载并运行.因此，(1)对我来说不是一个选择.
My app is really tiny and package/maintain it would be overkill. Plus, one of the requirements is that it should be download-and-run'able. So, (1) is not an opton for me.
静态链接(2)并不是一个不错的解决方案，但似乎没有libcurs附带的libopenssl，libcrypto和其他可传递依赖项的静态二进制分布.
Static link (2) would be not-bad solution but it seems that there is no static binary distributions of libopenssl, libcrypto and other transitive dependencies that come with libcurl.
从理论上讲，我可以尝试在libcurl后面手动构建所有的lib动物园，但这似乎会使维护变得更加复杂.
Theoretically I could try to build all that zoo of libs behind libcurl manually, but it seems that this will make maintenance much more complicated.
所以，这是一个问题-我错过了什么吗?有没有一种更轻松的方式来减轻我在linux世界中的痛苦(具体来说是Ubuntu)?欢迎任何建议.
So, here is the question - am I missing something? Is there a less painful way to do what I want in linux world (Ubuntu to be specific) with less pain? Any suggestions are welcomed.
推荐答案
我在我的项目中使用libcurl，这取决于openssl和一堆 其他.so在运行时.这种依赖是种痛苦， 因为不同的发行版/版本可能包含不同的openssl 版本.
I am using libcurl in my project and it depends on openssl and bunch of other .so in runtime. This dependency is kind of pain in the ass, since different distributives/versions may contain different openssl versions.
例如，如果我在Ubuntu 11.10上运行时遇到问题 在Ubuntu 9.10上编译了我的应用.
For example i am experiencing problems running on Ubuntu 11.10 if i compilled my app on Ubuntu 9.10.
首先，这是什么问题?如果您正在从旧版本的Ubuntu升级到新版本的Ubuntu，那么您应该不会有任何问题.如果我没有记错的话，您只需要指定所需的库的最低版本，程序包管理器就可以安装合适的版本.除非您使用的是已弃用的功能，否则新版本的库不应不会破坏现有应用.
First up, what is the problem with this? You shouldn't have problems if you're moving up from an older version of Ubuntu to a newer one. If I'm not mistaken, you only need to specify which minimum version of a library you need and the package manager should be able to install a suitable version. Newer versions of libraries should not break existing apps unless you're using deprecated features.
我的应用程序确实很小，并且打包/维护它可能会过大.加， 要求之一是它应可下载并运行. 因此，(1)对我来说不是一个选择.
My app is really tiny and package/maintain it would be overkill. Plus, one of the requirements is that it should be download-and-run'able. So, (1) is not an opton for me.
对于Linux(尤其是Ubuntu，Fedora和其他顶级发行版)，打包实际上是分发应用程序的 方法. Download-install-run是Windows的事情，不是Linux上的人安装软件的方式(嗯，刚接触Linux的人可能...)
For Linux (especially Ubuntu, Fedora and other top distros), packaging is really the way to distribute your application. Download-install-run is a Windows thing and it's not the way people on Linux install software (well, people new to Linux might...)
您还应该尝试接受发行版，这将逐渐减轻您的负担.至少要在Ubuntu上实现此目标的第一步是创建自己的PPA( https://help.launchpad .net/Packaging/PPA ).
You should also try for distro acceptance which will reduce your burden over time. The first step towards this, atleast on Ubuntu, is to create your own PPA (https://help.launchpad.net/Packaging/PPA).
静态链接(2)将是不错的解决方案，但似乎有 没有libopenssl，libcrypto和其他的静态二进制发行版 libcurl附带的传递依赖.
Static link (2) would be not-bad solution but it seems that there is no static binary distributions of libopenssl, libcrypto and other transitive dependencies that come with libcurl.
这通常是非常非常的事情.静态链接或仅将库与您的应用程序捆绑在一起会给您带来更新的负担，如果您不进行更新，则会产生影响.因此，我不推荐这种方法.详情请参阅此处: http://www.dwheeler.com /blog/2012/04/03/#insecure-libraries
This is usually a very very bad thing to do. Static linking or just bundling the library with your app puts the burden of updating it on you and there are implications if you don't update those. So, I don't recommend this approach. See here for more details: http://www.dwheeler.com/blog/2012/04/03/#insecure-libraries
以下是Fedora的政策: http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
Here is Fedora's policy: http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
所以，这是一个问题-我错过了什么吗?有没有一个 在Linux世界中做我想要的痛苦方式(具体来说是Ubuntu) 减轻痛苦?欢迎任何建议.
So, here is the question - am I missing something? Is there a less painful way to do what I want in linux world (Ubuntu to be specific) with less pain? Any suggestions are welcomed.
这里确实有两件事要做:
There really are two things to do here:
- 包装:理想情况下，对于Ubuntu/Debian，这将是deb，对于Fedora/Suse，这将是rpm.另一种流行的替代方法是使用自动工具(autoconf/automake)，以便用户可以使用所需的先决条件来构建您的应用程序.最后一个选择是仅提供Makefile和README，并期望您的用户做正确的事情.
- 发行版:理想情况下，这是与发行版存储库一起使用的. Ubuntu PPA是一个很好的起点.另一种方法是将二进制文件/程序包托管在您自己的网站上.
大多数流行的应用程序都为流行的Linux发行版提供.deb/.rpm以及具有自动工具的.tar.gz，它们可以在具有不同打包系统的发行版上进行构建.
Most popular applications provide both a .deb/.rpm for the popular Linux distros as well as .tar.gz with autotools for building on distros that have a different packaging system.
最后，让我问你一个问题:您是在专注于使您提供应用程序的痛苦减轻，还是使用户获得应用程序的痛苦减轻?
In the end, let me ask you this: is your focus on making it less painful for you to provide your application, or making it less painful for your users to obtain your application?
这篇关于处理Linux上的库依赖关系的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
