Другими словами, может ли приложение, работающее в одном дистрибутиве, быть просто скопировано и запущено в другом дистрибутиве?
4 ответа
5
Это зависит от того, как приложение собирается. Одной из проблем могут быть системные пути, которые могут отличаться от распределения к распределению. Другая проблема - это общие библиотеки, которые могут быть не установлены в целевой системе или, что еще хуже, могут быть установлены в несовместимых версиях.
Одним из решений проблемы библиотек является либо создание статически связанных двоичных файлов, либо (как это принято в 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)
Если все связанные библиотеки существуют в совместимой версии в целевой системе, скорее всего, ваше приложение сможет запуститься. С этого момента это в основном пути, которые должны быть скорректированы.
3
Это зависит от версии glibc среди других вещей. Обычно это не очень хорошая идея, поскольку структуры файловой системы могут отличаться.
2
Это зависит от сложности приложения, а также от зависимостей и библиотек, на которые оно ссылается.
Если приложение является автономным, простым, не имеет внешних зависимостей и скомпилировано на той же архитектуре процессора - оно должно работать.
В более сложных сценариях трудно сказать. Конечно, чтобы иметь какой-либо шанс, приложение должно быть для той же арки ЦП, той же версии glibc, и 2 дистрибутива должны быть с общей базой - то есть проще запускать приложение Debian в Ubuntu и т.д.
Если вы хотите создать такое приложение и иметь возможность запускать его в любом дистрибутиве - вам нужно скомпилировать его со статически связанными библиотеками и не передавать ни на макет файловой системы ОС, ни предполагать, что некоторые файлы будут расположены в определенном месте. местах.
Если бы вы создавали приложение не вы, то лучше использовать предварительно подготовленные пакеты конкретного дистрибутива или компилировать из исходного кода.
Все выше сказанное верно для "скомпилированного" приложения. Если это какое-то приложение на языке сценариев - ruby, php, perl, python и т.д., Скорее всего (если версия интерпретатора такая же), вы можете просто скопировать его - опять же, если приложение не предполагает, что некоторые файлы находятся в определенных местах. Но это может быть решено, так как вы можете изменить сценарий в соответствии с ходом.
0
Если архитектура процессора такая же, я не понимаю, почему это не сработает.