便携式共享对象？

Question

是否可以像Windows中的DLL那样以便携方式使用共享对象文件？

我想知道是否有一种方法可以为Linux提供一个可以使用的编译库。以同样的方式，您可以在Windows中编译DLL，它可以在任何其他Windows上使用（好吧，不是任何其他的，但在大多数情况下它可以）。

这可能在Linux中吗？

修改
我刚刚醒来并阅读了答案。有一些非常好的 我不是想隐藏源代码。我只想提供一个已经编译好并且可以使用的库，因此没有编译经验的用户不需要自己动手。
因此，我们的想法是提供一个可以在尽可能多的不同Linux上运行的.so文件 该库是用C ++编写的，使用STL和Boost库。

Answer 1

我高度 高度建议使用LSB应用/库检查器。它会告诉你，如果你：

• 正在使用某些发行版中没有的扩展程序
• 在安装脚本中引入bash-isms
• 使用所有近期内核中不可用的系统调用
• 取决于非标准库（它会告诉你哪些发行版缺少它们）
• 很多，很多其他非常好的支票

您可以获得more information here以及下载该工具。它易于运行..只需解压缩它，运行perl脚本并将浏览器指向localhost ..其余的是浏览器驱动的。

使用该工具，您可以轻松获得您的图书馆/应用程序LSB认证（适用于两个版本），并使发行包装工作更容易。

除此之外，只需使用libtool（或类似）之类的东西来确保您的库安装正确，为不想链接DSO的人提供静态对象（库需要时间才能显示）在大多数发行版中，所以写一个便携式程序，我不能指望它存在）并且很好地评论你的公共接口。

对于图书馆，我发现Doxygen效果最好。文档非常重要，它肯定会影响我选择的库以用于任何给定的任务。

真的，再次查看应用程序检查程序，它将为您提供可移植性问题报告，这将需要一年的时间让图书馆在野外出现以获得其他方式。

最后，尝试让你的图书馆很容易掉到“树上”，所以我不必静态链接它。正如我所说，它可能需要几年才能在大多数发行版中变得普遍。我更容易抓住你的代码，将它放在src / lib中并使用它，直到你的库是常见的。请，请给我单元测试，TAP（测试任何协议）是一种好的，可移植的方式。如果我破解你的库，我需要（快速）知道我是否破坏它，特别是在树中修改它或 en situ 时（如果存在DSO）。

Answer 2

如果您想通过提供已编译的代码来帮助您的用户，我知道的最好的方法是给他们一个静态链接的二进制文件+文档如何运行二进制文件。 （这可能是为了向它们提供源代码。）大多数静态链接的二进制文件适用于大多数相同体系结构的Linux发行版（+ 32位（x86）静态链接二进制文件在64位（amd64）上工作）。毫无疑问，Skype提供了静态链接的Linux下载。

回到你的图书馆问题。即使您是在Linux上编写共享库的专家，并且您花时间最小化依赖性，因此您的共享库可以在不同的Linux发行版（包括旧版本和新版本）上运行，因此无法确保它可以正常工作在未来（比方说，2年）。您最有可能最终维护.so文件，即一遍又一遍地进行小修改，以便.so文件与较新版本的Linux发行版兼容。长时间这样做并不好玩，并且会大大降低您的工作效率：您花在维护库兼容性上的时间会更好地用于例如提高软件的功能，效率，安全性等。

请注意，通过提供.so格式的库，很容易让用户感到不安，这在他们的系统上无效。 （并且你没有超级大国让它在所有 Linux系统上运行，所以这种情况是不可避免的。）你是否提供32位和64位，包括x86，PowerPC， ARM等？如果.so文件仅适用于Debian，Ubuntu和Red Hat（因为您没有时间将文件移植到更多发行版），您很可能会扰乱您的SUSE和Gentoo用户（以及更多）。

Answer 3

理想情况下，您需要使用GNU autoconf，automake和libtool来创建configure和make脚本，然后使用生成的configure和Makefile将库作为源分发。在文件中。

这是关于他们的online book。

./configure; make; make install在Linux中是相当标准的。

问题的根源在于Linux在许多不同的处理器上运行。您不能仅仅依赖支持x86指令的处理器，例如Windows（对于大多数版本：Itanium（XP和更新版本）和Alpha（NT 4.0）是例外情况。）

Answer 4

那么，问题是，如何为Linux开发共享库？您可以查看this tutorial或the Pogram Library Howto。

Answer 5

我知道你在问什么。对于Windows，MSFT已经仔细地使DLL完全兼容，因此您的DLL通常与几乎每个版本的Windows兼容，这就是您将其称为“可移植”的原因。

不幸的是，在Linux上有太多的变化（并且每个人都在考虑“不同”以赚钱），这样你就无法获得与Windows相同的好处，这就是为什么我们为不同的发行版编译了很多相同的包，发行版，CPU类型，......

有人说这个问题是由（CPU）架构引起的，但实际上并非如此。即使在相同的拱门上，分布之间仍然存在差异。一旦你真的试图发布二进制包，你就会知道它有多难 - 甚至很难维护C运行时库依赖。 Linux OS缺乏太多东西，所以几乎每个服务都涉及依赖问题。

通常，您只能构建一些与某些发行版兼容的二进制文件（或者，如果您很幸运，可以使用多个发行版）。这就是为什么以二进制方式发布Linux程序总是搞砸了，除非绑定到像Ubuntu，Debian或RH这样的发行版。

Answer 6

将.so文件放入/ usr / lib 可能会工作，但是你可能会搞乱你的发行版管理库的方案。

看一下linux标准库 - 这是你在Linux发行版中找到的最常见的平台。

http://www.linuxfoundation.org/collaborate/workgroups/lsb

你想要完成什么？

Answer 7

Tinkertim的回答很明显。我要补充一点，理解和规划对gcc's ABI的更改非常重要。最近情况相当稳定，我猜所有主要的发行版都在gcc 4.3.2左右。然而，每隔几年，一些change to the ABI（尤其是与C ++相关的位）似乎会引起混乱，至少对于那些想要发布跨发行版二进制文件的人以及习惯于从其他发行版中获取包的用户而言实际运行并发现它们有效。虽然其中一个转换正在进行（所有发行版都按照自己的进度升级），但理想情况下，您希望发布支持用户使用的所有gcc版本的ABI的库。