是否可以像 Windows 中的 DLL 一样以可移植的方式使用共享对象文件？
我想知道是否有一种方法可以为 Linux 提供一个可立即使用的编译库。就像您可以在 Windows 中编译 DLL 一样，它可以在任何其他 Windows 上使用（好的，不是任何其他的，但在大多数 Windows 上都可以）。
这在Linux中可能吗？
编辑：
我刚刚醒来并阅读了答案。有一些非常好的。
我不是想隐藏源代码。我只是想提供一个已经编译好的可以使用的库，所以没有编译经验的用户不需要自己做。
因此，我们的想法是提供一个可以在尽可能多的不同 Linux 上运行的 .so 文件。
该库是用 C++ 编写的，使用 STL 和 Boost 库。
我强烈 推荐使用 LSB 应用程序/库检查器。如果您：
您可以在此处获取更多信息以及下载该工具。它易于运行.. 只需解压它，运行 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 文件一起分发。
这是一本关于他们的在线书籍。
./configure; make; make install在Linux中是相当标准的。
问题的根源在于 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++ 相关的位）的一些更改似乎会造成混乱，至少对于那些想要发布跨发行版二进制文件的人和习惯于从其他发行版获取软件包而不是实际的用户而言运行并发现它们工作。虽然其中一个过渡正在进行（所有发行版都按照自己的节奏升级），但理想情况下，您希望发布带有 ABI 的库，以支持您的用户使用的所有 gcc 版本。