是否有可能像Windows中的DLL那样以便携的方式使用共享对象文件？
我想知道是否有一种方法可以为Linux提供一个编译好的库，可以使用。 就像你可以在Windows中编译一个DLL一样，它可以在任何其他Windows上使用（可以，不是任何其他的，但大部分都可以）。
在Linux中可能吗？
编辑：
我刚醒来就读了答案。 有一些非常好的。
我不想隐藏源代码。 我只想提供一个已经编译好的库，所以没有编译经验的用户不需要自己做。
因此，这个想法是提供一个可以在尽可能多的不同Linux上运行的.so文件。
该库是用C ++编写的，使用STL和Boost库。
我高度推荐使用LSB应用程序/库检查器。 它会告诉你，如果你：
您可以在这里获得更多信息以及下载该工具。 它很容易运行..只是解开它，运行一个Perl脚本，并指向您的浏览器在本地..其余的是浏览器驱动。
使用该工具，您可以轻松获得您的图书馆/应用程序LSB认证（适用于这两个版本），并使发行人的工作更容易。
除此之外，只需使用libtool（或类似的）来确保您的库安装正确，为不想链接到DSO的用户提供一个静态对象（需要一段时间才能使您的库出现在大多数分发版中，所以写一个可移植的程序，我不能指望它存在），并很好地评论你的公共接口。
对于图书馆，我发现Doxygen工作得最好。 文件是非常重要的，它肯定会影响我选择图书馆用于任何给定的任务。
真的，再次，检查应用程序检查，它会给你的便携性问题报告，需要一年的时间，在野外图书馆获得否则。
最后，尽量让你的图书馆容易放在“树”，所以我不必静态链接它。 正如我所说，在大多数发行版中，这可能需要几年时间才会变得很普遍。 它更容易让我抓住你的代码，把它放在src / lib中并使用它，直到你的库很常见。 请，请给我单元测试， TAP （测试任何协议）是一个很好的和便携的方式来做到这一点。 如果我破解了你的库，我需要知道（很快）是否破坏了它，特别是在树中或在原地修改（如果DSO存在的话）。
如果你想通过给用户编译代码来帮助你的用户，我所知道的最好的方法就是给他们一个静态链接的二进制文件，以便他们如何运行这个二进制文件。 （这可能是除了给他们的源代码之外）。大多数静态链接的二进制文件在同一架构（+ 32位（x86）静态链接的二进制文件在64位（amd64）上工作）的大多数Linux发行版上工作。 难怪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来创建配置和制作脚本，然后使用生成的配置文件和Makefile.in文件将库作为源进行分发。
这是一本关于他们的在线书籍 。
./configure; make; make install 在Linux中./configure; make; make install相当标准。
问题的根源在于Linux在许多不同的处理器上运行。 你不能只依赖支持像Windows那样的x86指令的处理器（对于大多数版本：Itanium（XP和更新）和Alpha（NT 4.0）是例外）。
那么问题是，如何开发Linux共享库？ 你可以看看这个教程或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的ABI进行更改是非常重要的 。 最近事情已经相当稳定了，我想所有的主要发行版都在gcc 4.3.2左右。 然而，每隔几年ABI （特别是与C ++相关的部分）的一些变化似乎就会造成混乱，至少对那些想要发行跨平台发行版的用户来说，以及那些习惯于从其他发行版中拾取软件包的用户运行并找到他们的工作。 尽管其中一个转换正在进行（所有发行版都按照自己的速度升级），但您最好还是希望使用支持用户使用的全系列gcc版本的ABI来发布库。