☰

Linux 发行版是否相互兼容？

tag-icon • tag-icon compatibility linux-distributions
Linux 发行版是否相互兼容？

换句话说，在一个发行版上运行的应用程序可以简单地复制并在另一个发行版上运行吗？

答案1

这取决于应用程序的构建方式。一个问题可能是系统路径可能因发行版而异。另一个问题是共享库可能未安装在目标系统上，或者更糟的是，可能安装在不兼容的版本中。

解决库问题的一个方法是构建静态链接的二进制文件或（像在 OS X 上很常见的那样）仅将所有必需的库与应用程序一起发送，并在必要时相应地设置 LD_LIBRARY_PATH（尽管出于很多原因这不是一个好主意）。

检查程序是否能运行的一个简单方法是使用 ldd 列出所有链接库，并查看它们是否存在于目标系统上。

使用 apache httpd 的示例：

[lukas@web1 /]$ ldd /usr/sbin/httpd
        libm.so.6 => /lib64/libm.so.6 (0x00002b1ec3aaf000)
        libpcre.so.0 => /lib64/libpcre.so.0 (0x00002b1ec3d32000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00002b1ec3f4e000)
        libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00002b1ec4167000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002b1ec4384000)
        libldap-2.3.so.0 => /usr/lib64/libldap-2.3.so.0 (0x00002b1ec45bc000)
        liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x00002b1ec47f7000)
        libdb-4.3.so => /lib64/libdb-4.3.so (0x00002b1ec4a05000)
        libexpat.so.0 => /lib64/libexpat.so.0 (0x00002b1ec4cfa000)
        libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00002b1ec4f1d000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b1ec5144000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00002b1ec535f000)
        libc.so.6 => /lib64/libc.so.6 (0x00002b1ec5564000)
        libsepol.so.1 => /lib64/libsepol.so.1 (0x00002b1ec58bb000)
        /lib64/ld-linux-x86-64.so.2 (0x00002b1ec3892000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00002b1ec5b01000)
        libpq.so.4 => /usr/lib64/libpq.so.4 (0x00002b1ec5d06000)
        libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00002b1ec5f28000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00002b1ec6183000)
        libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002b1ec6399000)
        libssl.so.6 => /lib64/libssl.so.6 (0x00002b1ec65b2000)
        libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002b1ec67fc000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002b1ec6b4e000)
        libnsl.so.1 => /lib64/libnsl.so.1 (0x00002b1ec6de3000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002b1ec6ffc000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002b1ec722a000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002b1ec742c000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00002b1ec7652000)
        libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002b1ec7866000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002b1ec7a6e000)

如果所有链接库在目标系统上都存在兼容版本，您的应用程序很可能能够启动。从那时起，大部分路径都必须进行调整。

答案2

这取决于 glibc 版本等。通常不是这是一个好主意，因为文件系统结构可能会有所不同。

答案3

这取决于应用程序的复杂性，以及它链接到的依赖项和库。

如果应用程序是独立的、简单的、没有外部依赖关系并且在相同的 CPU 架构上编译 - 它应该可以工作。

在更复杂的情况下，很难说。当然，为了有任何机会，应用程序需要使用相同的 CPU 架构、相同的 glibc 版本，并且 2 个发行版需要具有共同的基础 - 即在 ubuntu 上运行 debian 应用程序更容易，等等。

如果您想构建这样的应用程序，并能够在任何发行版上运行它 - 那么您需要使用静态链接库对其进行编译，并且不要依赖于操作系统文件系统布局，并假设某些文件位于特定位置。

如果不是您构建了应用程序，那么最好使用特定发行版的预构建包，或者从源代码进行编译。

以上内容适用于“已编译”应用程序。如果是某种脚本语言应用程序 - ruby​​、php、perl、python 等，则很可能（如果解释器版本相同）您可以直接复制它 - 同样，如果应用程序不假设某些文件位于特定位置。但这可以解决，因为您可以修改脚本以适应移动。

答案4

如果处理器架构相同，我不明白为什么这行不通。

相关内容