可移植共享对象？
是否可以像 Windows 中的 DLL 一样以可移植的方式使用共享对象文件？
我想知道是否有一种方法可以为 Linux 提供一个可供使用的编译库。 就像你可以在 Windows 中编译 DLL 一样，它也可以在任何其他 Windows 上使用（好吧，不是任何其他 Windows，但在大多数 Windows 上都可以）。
这在 Linux 中可能吗？
编辑：
我刚刚醒来并阅读了答案。 有一些非常好的。
我并不是想隐藏源代码。 我只是想提供一个已经编译好即可使用的库，这样没有编译经验的用户就不需要自己动手了。
因此，我们的想法是提供一个可以在尽可能多的不同 Linux 上运行的 .so 文件。
该库是用 C++ 编写的，使用 STL 和 Boost 库。
Is it possible to use shared object files in a portable way like DLLs in Windows??
I'm wondering if there is a way I could provide a compiled library, ready to use, for Linux. As the same way you can compile a DLL in Windows and it can be used on any other Windows (ok, not ANY other, but on most of them it can).
Is that possible in Linux?
EDIT:
I've just woke up and read the answers. There are some very good ones.
I'm not trying to hide the source code. I just want to provide an already-compiled-and-ready-to-use library, so users with no experience on compilation dont need to do it themselves.
Hence the idea is to provide a .so file that works on as many different Linuxes as possible.
The library is written in C++, using STL and Boost libraries.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我强烈强烈推荐使用 LSB 应用/库检查器。 它会很快告诉您，如果您：
您可以获得更多信息在这里以及下载该工具。 它很容易运行.. 只需解压它，运行 perl 脚本并将浏览器指向本地主机.. 其余的由浏览器驱动。
使用该工具，您可以轻松地让您的库/应用程序获得 LSB 认证（对于两个版本），并使发行版打包者的工作变得更加轻松。
除此之外，只需使用 libtool （或类似的）之类的东西来确保您的库安装正确，为不想链接到 DSO 的人提供一个静态对象（您的库需要一段时间才能出现在大多数发行版中） ，因此编写一个可移植程序，我不能指望它存在）并很好地评论您的公共界面。
对于库，我发现 Doxygen 效果最好。 文档非常重要，它肯定会影响我对用于任何给定任务的库的选择。
真的，再次检查一下应用程序检查器，它会给你可移植性问题报告，否则需要一年的时间才能获得该库。
最后，尝试使您的库易于“放入树中”，这样我就不必静态链接它。 正如我所说，它可能需要几年时间才能在大多数发行版中变得普遍。 对我来说，获取你的代码，将其放入 src/lib 并使用它要容易得多，直到你的库是通用的为止。 请，请..给我单元测试， TAP （测试任何协议）是一个很好的、便携的方法来做到这一点。 如果我破解了你的库，我需要（快速）知道我是否破坏了它，特别是在树或原位修改它时（如果 DSO 存在）。
I highly highly recommend using the LSB app / library checker. Its going to tell you quickly if you:
You can get more information here as well as download the tool. Its easy to run .. just untar it, run a perl script and point your browser at localhost .. the rest is browser driven.
Using the tool, you can easily get your library / app LSB certified (for both versions) and make the distro packager's job much easier.
Beyond that, just use something like libtool (or similar) to make sure your library is installed correctly, provide a static object for people who don't want to link against the DSO (it will take time for your library to appear in most distributions, so writing a portable program, I can't count on it being present) and comment your public interface well.
For libraries, I find that Doxygen works the best. Documentation is very important, it surely influences my choice of library to use for any given task.
Really, again, check out the app checker, its going to give you portability problem reports that would take a year of having the library out in the wild to obtain otherwise.
Finally, try to make your library easy to drop 'in tree', so I don't have to statically link against it. As I said, it could take a couple of years before it becomes common in most distributions. Its much easier for me to just grab your code, drop it in src/lib and use it, until and if your library is common. And please, please .. give me unit tests, TAP (test anything protocol) is a good and portable way to do that. If I hack your library, I need to know (quickly) if I broke it, especially when modifying it in tree or en situ (if the DSO exists).
如果您想通过为用户提供编译后的代码来帮助他们，我知道的最好方法是为他们提供静态链接的二进制文件+如何运行二进制文件的文档。 （这可能是除了向他们提供源代码之外的额外费用。）大多数静态链接的二进制文件都可以在相同架构的大多数 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 用户（以及更多）感到不安。
If you'd like to help your users by giving them compiled code, the best way I know is to give them a statically linked binary + documentation how they can run the binary. (This is possibly in addition to giving the source code to them.) Most statically linked binaries work on most Linux distributions of the same architecture (+ 32-bit (x86) statically linked binaries work on 64-bit (amd64)). It is no wonder Skype provides a statically linked Linux download.
Back to your library question. Even if you are in an expert in writing shared libraries on Linux, and you take your time to minimize the dependencies so your shared library would work on different Linux distributions, including old and new versions, there is no way to ensure that it will work in the future (say, 2 years). You'll most probably end up maintaining the .so file, i.e. making small modifications over and over again so the .so file becomes compatible with newer versions of Linux distributions. This is no fun doing for a long time, and it decreases your productivity substantially: the time you spend on maintaining the library compatibility would have been much better spent on e.g. improving the functionality, efficiency, security etc. of the software.
Please also note that it is very easy to upset your users by providing a library in .so form, which doesn't work on their system. (And you don't have the superpower to make it work on all Linux systems, so this situation is inevitable.) Do you provide 32-bit and 64-bit as well, including x86, PowerPC, ARM etc.? If the .so file works only on Debian, Ubuntu and Red Hat (because you don't have time time to port the file to more distributions), you'll most probably upset your SUSE and Gentoo users (and more).
理想情况下，您需要使用 GNU autoconf，automake 和 libtool 创建configure和make脚本，然后将库作为源代码与生成的configure和Makefile.in文件一起分发。
这是关于它们的在线书籍。
<代码>./配置; 制作; make install 在 Linux 中是相当标准的。
问题的根源在于Linux运行在许多不同的处理器上。 您不能像 Windows 那样仅仅依赖支持 x86 指令的处理器（对于大多数版本：Itanium（XP 和更新版本）和 Alpha (NT 4.0) 是例外）。
Ideally, you'll want to use GNU autoconf, automake, and libtool to create configure and make scripts, then distribute the library as source with the generated configure and Makefile.in files.
Here's an online book about them.
./configure; make; make installis fairly standard in Linux.The root of the problem is that Linux runs on many different processors. You can't just rely on the processor supporting x86 instructions like Windows does (for most versions: Itanium (XP and newer) and Alpha (NT 4.0) are the exceptions).
那么，问题来了，如何为Linux开发共享库呢？ 您可以查看本教程或程序库指南。
So, the question is, how to develop shared libraries for Linux? You could take a look at this tutorial or the Pogram Library Howto.
我知道你在问什么。 对于 Windows，MSFT 精心地使 DLL 全部兼容，因此您的 DLL 通常与几乎每个版本的 Windows 兼容，这就是为什么您称其为“可移植”。
不幸的是，在 Linux 上有太多的变体（每个人都想通过“与众不同”来赚钱），因此你无法获得与 Windows 相同的好处，这就是为什么我们为不同的发行版、发行版版本编译了许多相同的软件包， CPU类型，...
有人说问题是由（CPU）架构引起的，但事实并非如此。 即使在相同的架构上，发行版之间仍然存在差异。 一旦你真正尝试过发布一个二进制包，你就会知道它有多么困难——即使是 C 运行时库依赖也很难维护。 Linux操作系统缺少太多的东西，所以几乎每个服务都涉及依赖问题。
通常，您只能构建一些与某些发行版兼容的二进制文件（或者，如果幸运的话，可以与多个发行版兼容）。 这就是为什么以二进制形式发布 Linux 程序总是会搞砸，除非绑定到 Ubuntu、Debian 或 RH 等发行版。
I know what you are asking. For Windows, MSFT has carefully made the DLLs all compatible, so your DLLs are usually compatible for almost every version of Windows, that's why you call it "portable".
Unfortunately, on Linux there are too many variations (and everyone is thinking to be "different" to make money) so that you cannot get same benefits as Windows, and that's why we have lots of same packages compiled for different distributions, distro version, CPU type, ...
Some say the problem is caused by (CPU) architecture, but it is not. Even on same arch, there's still different between distributions. Once you've really tried to release a binary package, you would know how much hard it is - even C runtime library dependency is hard to maintain. Linux OS lacks too much stuff so almost every services involves dependency issue.
Usually you can only build some binary that is compatible to some distribution (or, several distributions if you are lucky). That's why releasing Linux programs in binary always screwed up, unless bound to some distro like Ubuntu, Debian, or RH.
只需将 .so 文件放入 /usr/lib可能就可以了，但是您可能会搞乱发行版用于管理库的方案。
看一下 Linux 标准库——这是你能在 Linux 发行版中找到的最接近通用平台的东西。
http://www.linuxfoundation.org/collaborate/workgroups/lsb
你是什么试图完成？
Just putting a .so file into /usr/lib may work, but you are likely to mess up the scheme that your distro has for managing libraries.
Take a look at the linux standard base - That is the closest thing you will find to a common platform amongst linux distros.
http://www.linuxfoundation.org/collaborate/workgroups/lsb
What are you trying to accomplish?
Tinkertim 的回答是正确的。 我要补充一点，了解和计划对 gcc 的 ABI 的更改非常重要。 最近情况相当稳定，我猜所有主要发行版都在 gcc 4.3.2 左右。 然而，每隔几年，ABI 就会发生一些变化（尤其是 C++ 相关位）造成混乱，至少对于那些想要发布跨发行版二进制文件的人以及习惯于从其他发行版获取软件包而不是实际运行并发现它们可以工作的用户来说。 当这些转变之一正在进行时（所有发行版都按照自己的节奏升级），您理想情况下希望发布具有支持用户使用的全系列 gcc 版本的 ABI 的库。
Tinkertim's answer is spot on. I'll add that it's important to understand and plan for changes to gcc's ABI. Things have been fairly stable recently and I guess all the major distros are on gcc 4.3.2 or so. However, every few years some change to the ABI (especially the C++ related bits) seems to cause mayhem, at least for those wanting to release cross-distro binaries and for users who have gotten used to picking up packages from other distros than they actually run and finding they work. While one of these transitions is going on (all the distros upgrade at their own pace) you ideally want to release libs with ABIs supporting the full range of gcc versions in use by your users.