我的Linux二进制文件可以在所有发行版上使用吗？

我找到了一个很好的替代Delphi的IDE，叫做Lazarus。但是我对程序员没有问题。

请问静态链接上的所有Linux发行版的Linux二进制工作？也就是说，在我构建的Linux发行版上都没有关系，它可以在Debian / ArchLinux / Ubuntu / OpenSUSE / ...上运行。

根据我的发现，真的只有32位与64位有关系吗？在发布之前，我想确定一下。

该答案最初是针对更笼统的问题“我的二进制文件将在所有发行版上运行”而写的，但是它在下半部分解决了静态链接的二进制文件。

对于比静态链接的hello世界更复杂的事情，答案可能是“否”。
如果未在分布X上对其进行测试，则假定答案是否定的。

如果您想以二进制形式发布软件，请限制于

• 有关软件使用领域的一些流行发行版（台式机，服务器，嵌入式等）

• 每个版本的最新一两个版本

否则，您最终将获得各种大小，版本和年龄的发行版（仍在使用和支持十年的发行版）。

测试那些。否则，可能会（或将会）出错的地方只有几个指针：

• 您需要的工具/库的软件包在各个发行版甚至同一发行版的版本中都具有不同的名称

• 您需要的库太新或太旧（版本错误）。不要仅仅因为您的程序可以链接就假设它会链接到正确的库。

• 相同的库（磁盘上的文件）在不同的发行版中具有不同的名称，因此无法进行链接

• 64位上的32位：可能未安装32位环境，或者将一些非必需的32位库移入了32on64环境之外的其他程序包中，因此仅在这种情况下具有额外的依赖性。

• Shell：不要假设您使用的是Bash版本。甚至不要假设Bash。

• 工具：不要假设任何非POSIX命令行工具都存在。

• 工具：不要仅仅因为发行版的GNU版本就可以识别该工具即可。

• 内核接口：不要/proc仅仅因为文件存在/具有您的计算机上的结构就假定文件的存在或结构

• Java：您真的确定您的程序无需测试就可以在SLES附带的IBM JRE上运行吗？

奖金：

• 指令集：在计算机上编译的二进制文件无法在较旧的硬件上运行。

是静态链接（或：捆绑所有你需要用你的软件库）的解决方案？即使在技术上可行，相关的成本也可能很高。因此，不幸的是，答案可能都不是。

• 安全性：您将更新库的责任从软件用户转移到您自己。

• 大小和复杂性：仅出于娱乐目的，尝试构建静态链接的GUI程序。

• 互操作性：如果您的软件是任何形式的“插件”，则取决于调用您的软件。

• 库设计：如果您将程序静态链接到GNU libc并使用名称服务（getpwnam()等等），最终将针对libc的NSS（名称服务开关）进行动态链接。

• 库设计：使用数据文件或其他资源（如时区或语言环境）将程序与程序静态链接的库。

由于上述所有原因，测试是必不可少的。

• 熟悉KVM或其他虚拟化技术，并拥有打算支持的每个发行版的VM。在每个VM上测试您的软件。

• 使用这些发行版的最少安装。

• 创建具有受限指令集的VM（例如，没有SSE 4）。

• 仅静态链接或捆绑：使用二进制文件检查ldd它们是否真的是静态链接/仅使用捆绑的库。

• 仅静态链接或捆绑：创建一个空目录并将您的软件复制到其中。chroot进入该目录并运行软件。

答案是取决于。，但是在大多数情况下，是的，只要在操作系统上安装了必要的库即可。

通常，大多数大型发行版（例如您提到的发行版）都具有其软件包管理工具，这些工具可以安装社区维护的应用程序版本。这可以照顾到应用程序所需的任何必备软件包。如果要在没有软件包管理器的情况下进行安装，则要确保所有必需的软件包和库都已安装到操作系统上。在文档中包括这些必备应用程序的列表是个好主意。

脚的答案：这取决于

如果您正在发布的二进制文件，假设的答案是“不”，除非你正在分发所有的库，它曾经与它包括（从地上爬起来，除非你是提供自成一体反正一个非常庞大的系统，这是烦人）或静态链接等效项。

...但是巫师和金钱，还有金钱巫师...

IBM有一些“通用的Unixish”安装程序，它们在我尝试过的所有地方都使我感到震惊：来自几代内核，OpenSolaris（或现在称为的），Solaris和BSD的几种Linuces。但是它们很大。他们提供的东西同样巨大。用这种方式不会发布任何精巧的赛车程序，只有您期望从IBM获得的大型企业型东西。

至于仅停留在Linux上，但在大多数Linuxdom上都能很好地工作，这似乎可以二进制形式进行，这可以从某些供应商处看到的各种“ for Linux（通用）”类型的二进制安装程序中得到了证明。这种方式发布了一些聊天，浏览器，游戏，元安装程序等，但是总是由大型供应商提供，他们可以花一些时间来解决这个问题。他们可以说“ for Linux”，并且普遍相信它会起作用，这真是令人惊讶，但是事实确实如此。

但...

我通过构建实用程序将软件作为源进行分发。我做这在C，二郎，Python和狡诈等，这给了我很多关于它是否将运行与否更多的灵活性，而这是很容易写一个buildscript是确保在构建时存在正确的事情，而不是确保在运行时一切就绪。一旦存在，如果分发源代码，则为程序编写自动更新程序将变得很简单：源代码通常比包含所有部门和其他精神错乱的二进制文件小很多。使用此方法，我在跨Unices（有时是Windows）中可靠地部署时并没有很多麻烦，但这有点麻烦。

足够的戏弄，武装自己！

当您像srsly srs一样认真对待要在Linux世界中顺利适应时，您可以分发C源代码或转向完全托管的环境来使用已经预先构建的令人讨厌的令人愉悦的语言。例如，如果您正在编写Python代码，则可以检查版本并知道您使用的CPython版本，并且通常希望在给定的Linux上存在一些兼容的版本（这比检查广泛的C库要容易得多。 / versions（您可能正在使用）。Erlang，Guile，Python，Perl，CL等都非常出色 这类部署的目标很简单，其中许多都有中央存储库，例如CPAN或pip（或其他），用户可以在其中运行命令以在需要时自己拉动签名源，并知道事情通常会按预期工作。

[附录：1. 即使Haskell通常也可以通过Cabal实现这一目标 -尽管我会在生产环境中谨慎行事。2. Erlang有完全不同的“发布”部署策略，可确保您的代码带有完整的环境。3. Python在虚拟环境方面走了一步。并非所有的运行时都对您有所帮助。]

关于Linux上的托管环境的最后一点令人震惊。而且，作为一项奖励，它使您可以定义更多一般性的依赖关系，无需您付出额外的努力即可自动解决它们，不需要为每个发行版编写程序包，并且您可以停止关心系统是32还是64位（通常，无论如何）。