Поддерживает ли python + pyinstaller несколько ОС/версий Linux?
Я написал несколько небольших скриптов на python и собрал бинарники с помощью pyinstaller.
Когда я собирал их на своей машине с Ubuntu 16.04, они нормально работали на машине, на которой я их собирал. Но перемещение файла на машину Centos/Redhat 7.4 дало бы мне GCLIB и другие ошибки зависимости версии .so.
- Сборка того же бинарного файла на докере с той же версией Centos не приведет к этим ошибкам.
- Если я попытаюсь запустить двоичный файл, скомпилированный на Centos 7.4, на Centos 6.6, я снова получу ошибки, но сборка на Centos 6.6 будет корректно работать с Centos 6.6.
Я решил проблему, используя более низкую версию Centos для сборки моих двоичных файлов на данный момент.
- Мой конкретный вопрос: в Python это распространенный подход к созданию двоичных файлов в разных ОС на основе целевой ОС, для которой он предназначен (при условии, что только для целей Linux), или то, что я делаю, - это взлом/плохой способ решения Эта проблема?
Я пытаюсь понять, как эта проблема решается стандартным способом.
вам нужно, чтобы ваши сценарии были двоичными? Потому что если нет, то ваша проблема действительно решена. И вы все еще можете построить для окон, если это необходимо. Или вы можете прочитать о таких пакетах, как snap.
Это сценарии, но иногда им может потребоваться подключение к базам данных, которые затем используют внешние библиотеки. Целевые серверы не имеют доступа к Интернету. Это оставляет мне возможность создать двоичный файл и поделиться им с операционной командой. Предоставление целой папки зависимостей (которая, я не уверен, будет работать всегда) или настройка репозитория pip (серверам не предоставляется доступ в Интернет). Читаю ответ @Brian Campbell. Докер кажется разумным путем, чтобы облегчить работу операторам.
Ответы 1
Поскольку двоичный файл, созданный pyinstaller, зависит только от glibc, то его сборка на самой старой доступной системе должна быть допустимым подходом, и он должен работать на будущих системах.
В общем, glibc спроектирован так, чтобы быть обратно совместимым, так что приложения, созданные для более старой версии glibc, будут по-прежнему работать с более новой glibc, но не наоборот. Он делает это с помощью управления версиями символов, при котором каждый символ, на который вы ссылаетесь, может иметь связанную с ним версию, и в любом случае, когда более новый glibc изменил ABI какой-либо функции, он также будет иметь процедуру совместимости со старым ABI. со старой версией символа, так что приложения, связанные со старой версией, будут динамически связываться с подпрограммой совместимости, в то время как если у вас есть приложение, связанное с более новыми версиями символов, в более старой версии glibc не будет новых версий для динамической связи. к.
Хотя другие библиотеки также могут это делать, не многие авторы библиотек утруждают себя этим, поэтому более новые версии могут быть просто несовместимы, в то время как разработчики glibc обычно стараются сохранить совместимость.
Так что да, пока окончательный двоичный файл ссылается только на glibc или на другие библиотеки, которые следуют аналогичной схеме управления версиями символов, чтобы гарантировать, что старые двоичные файлы по-прежнему будут правильно связываться с более новыми версиями библиотеки, вполне допустимо создавать против более старой версию, а затем запускать ее на более новых версиях различных дистрибутивов Linux, и даже в целом на разных дистрибутивах.
К сожалению, нет хорошего способа заставить компоновщика выбирать более старые версии символов при компоновке с более новым glibc, поэтому часто самый простой способ сделать это — внутри Docker или контейнера другого типа, содержащего более старый дистрибутив с самым старым glibc, который вы хотите быть совместимым с.
docker может быть излишним здесь. А как насчет snap?
Справедливо. Отвечает на мой вопрос. Спасибо! :)
@MarcinOrlowski Вот почему я упомянул «или другой контейнер». Используйте технологию контейнера или системы сборки по вашему выбору, будь то docker, snap, pbuilder или что-то еще. Пока вы можете использовать его для запуска процесса сборки самого старого дистрибутива, который вы хотите поддерживать, все будет хорошо.
Я скорее имел в виду, что docker менее подходит для нужд OP, чем snap. Дело не в том, что все технологии контейнеров одинаковы, но с разными именами.
Pyinstaller не имеет большого значения в Linux. Это более распространено для Windows в качестве целевой ОС. В Linux больше пакетов устанавливается через
pip, который также заботится о бинарных зависимостях. Но они проблематичны, поскольку необходимо установить полную систему сборки и библиотеки. Существуют такие системы, как Docker или AppImage (и другие), решающие эту проблему за счет места.