是否可以像Windows中的DLL一样以可移植的方式使用共享对象文件？
我想知道是否有一种方法可以为Linux提供一个可以使用的编译库。以同样的方式，您可以在Windows中编译DLL，它可以在任何其他Windows上使用（好吧，不是任何其他Windows，但在大多数情况下它可以）。
这可能在Linux中吗？
编辑： 我刚刚醒来并阅读了答案。有一些非常好的。 我不是想隐藏源代码。我只是想提供一个已经编译并且可以使用的库，因此没有编译经验的用户不需要自己动手。 因此，我们的想法是提供一个可以在尽可能多的不同Linux上运行的.so文件。 该库是用C ++编写的，使用STL和Boost库。
我强烈建议使用LSB app / library checker。它会告诉你如果你：
您可以获得more information here以及下载该工具。它易于运行..只需解压缩它，运行perl脚本并将浏览器指向localhost ..其余的是浏览器驱动的。
使用该工具，您可以轻松获得您的库/应用程序LSB认证（两个版本），并使发行包装工作更容易。
除此之外，只需使用类似libtool（或类似）的东西来确保您的库安装正确，为不想链接DSO的人提供静态对象（您的库需要时间才能出现在大多数发行版中） ，所以写一个便携式程序，我不能指望它存在）并很好地评论你的公共接口。
对于图书馆，我发现Doxygen效果最好。文档非常重要，它肯定会影响我选择的库以用于任何给定的任务。
实际上，再次检查应用程序检查程序，它将为您提供可移植性问题报告，这将需要一年的时间让图书馆在野外出现以获得其他方式。
最后，尝试使您的库容易“放入树中”，因此我不必静态链接它。正如我所说，它可能需要几年才能在大多数发行版中变得普遍。我更容易抓住你的代码，将它放在src / lib中并使用它，直到你的库是常见的。请，请给我单元测试，TAP（测试任何协议）是一个很好的，可移植的方式来做到这一点。如果我破解你的图书馆，我需要知道（很快）我是否打破它，特别是在树或原地修改它时（如果存在DSO）。
如果您想通过提供编译代码来帮助您的用户，我知道的最好方法是给他们一个静态链接的二进制文件+文档如何运行二进制文件。 （这可能是为了向它们提供源代码。）大多数静态链接的二进制文件适用于大多数相同体系结构的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用户（以及更多）。
理想情况下，您需要使用GNU autoconf，automake和libtool来创建configure和make脚本，然后使用生成的configure和Makefile.in文件将库作为源分发。
这是关于他们的online book。
./configure; make; make install在Linux中是相当标准的。
问题的根源是Linux在许多不同的处理器上运行。你不能只依赖像Windows那样支持x86指令的处理器（对于大多数版本：Itanium（XP和更新版本）和Alpha（NT 4.0）是例外）。
那么，问题是，如何为Linux开发共享库？你可以看看this tutorial或the Pogram Library Howto。
我知道你在问什么。对于Windows，MSFT已经仔细地使DLL完全兼容，因此您的DLL通常兼容几乎每个版本的Windows，这就是您将其称为“可移植”的原因。
不幸的是，在Linux上有太多的变化（并且每个人都认为“赚钱”是“不同的”）因此你不能获得与Windows相同的好处，这就是为什么我们为不同的发行版编译了很多相同的包，发行版， CPU类型，......
有人说这个问题是由（CPU）架构引起的，但事实并非如此。即使在相同的拱门上，分布之间仍然存在差异。一旦你真的试图发布二进制包，你就会知道它有多难 - 甚至很难维护C运行时库依赖。 Linux操作系统缺少太多东西，所以几乎每个服务都涉及依赖问题。
通常，您只能构建一些与某些发行版兼容的二进制文件（或者，如果您很幸运，可以使用多个发行版）。这就是为什么以二进制方式发布Linux程序总是搞砸了，除非绑定到像Ubuntu，Debian或RH这样的发行版。
只需将.so文件放入/ usr / lib就可以了，但是你可能会搞乱你的发行版管理库的方案。
看一下linux标准库 - 这是你在Linux发行版中找到一个通用平台最接近的东西。
http://www.linuxfoundation.org/collaborate/workgroups/lsb
你想达到什么目的？
Tinkertim的回答很明显。我要补充一点，理解并计划改变gcc's ABI非常重要。最近情况相当稳定，我猜所有主要的发行版都在gcc 4.3.2左右。然而，每隔几年，一些change to the ABI（特别是与C ++相关的位）似乎会引起混乱，至少对于那些想要发布跨发行版二进制文件的用户以及习惯于从其他发行版中获取包而不是实际运行和查找的用户他们工作。虽然其中一个转换正在进行（所有发行版都按照自己的进度升级），但理想情况下，您希望发布支持用户使用的所有gcc版本的ABI的库。