Являются ли дистрибутивы Linux взаимно совместимыми?

Другими словами, может ли приложение, работающее на одном дистрибутиве, быть просто скопировано и запущено на другом дистрибутиве?

Это зависит от того, как приложение собирается. Одной из проблем могут быть системные пути, которые могут различаться в зависимости от распределения. Другая проблема - это общие библиотеки, которые могут быть не установлены в целевой системе, или, что еще хуже, могут быть установлены в несовместимых версиях.

Одним из решений проблемы библиотек является либо создание статически связанных двоичных файлов, либо (как это принято в 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)

Если все связанные библиотеки существуют в совместимой версии в целевой системе, скорее всего, ваше приложение сможет запуститься. С этого момента это в основном пути, которые должны быть скорректированы.

Это зависит от версии glibc среди других вещей. Его вообще не хорошая идея, поскольку структура файловой системы может отличаться.

Это зависит от сложности приложения, а также от зависимостей и библиотек, на которые оно ссылается.

Если приложение является автономным, простым, не имеет внешних зависимостей и скомпилировано на той же архитектуре процессора - оно должно работать.

В более сложных сценариях трудно сказать. Конечно, чтобы иметь какой-либо шанс, приложение должно быть для той же арки ЦП, той же версии glibc, и 2 дистрибутива должны быть с общей базой - то есть проще запускать приложение Debian в Ubuntu и т. Д.

Если вы хотите создать такое приложение и иметь возможность запускать его в любом дистрибутиве - вам нужно скомпилировать его со статически связанными библиотеками, а также не передавать ни на макет файловой системы ОС, ни предполагать, что некоторые файлы будут расположены в определенном месте. местах.

Если бы вы создавали приложение не вы, то лучше использовать предварительно подготовленные пакеты конкретного дистрибутива или компилировать из исходного кода.

Все выше сказанное верно для «скомпилированного» приложения. Если это какое-то приложение на языке сценариев - ruby, php, perl, python и т. Д., Скорее всего (если версия интерпретатора такая же), вы можете просто скопировать его - снова, если приложение не предполагает, что некоторые файлы находятся в определенных местах. Но это можно решить, так как вы можете изменить сценарий в соответствии с ходом.

Если архитектура процессора такая же, я не понимаю, почему это не сработает.