Блог

Я пытаюсь немного глубже разобраться в бинарных пакетах с помощью python в формате wheel, и я подумал, что мог бы попытаться дать wheelifying одну из моих зависимостей в качестве упражнения.

Чтобы максимизировать возможность повторного использования полученного пакета, я хочу собрать его с использованием manylinux контейнеров, которые компилируют двоичные файлы, включенные в пакет, с наименьшим общим знаменателем, с которым я, вероятно, столкнусь. Однако я не уверен, как избежать привязки к конкретному libpython.so . Документы описывают это довольно абстрактно:

Обратите внимание, что libpythonX.Y.so.1 отсутствует в списке библиотек, на которые разрешено ссылаться расширению manylinux1. Явная привязка к libpythonX.Y.so.1 не требуется почти во всех случаях: способ, которым работает привязка ELF, модули расширения, загружаемые в интерпретатор, автоматически получают доступ ко всем символам интерпретатора, независимо от того, связано ли само расширение явно с libpython. Кроме того, явная привязка к libpython создает проблемы в общей конфигурации, где Python не собран с помощью —enable-shared . В частности, в системах Debian и Ubuntu apt устанавливает pythonX.Y даже не устанавливает libpythonX.Y.so.1, что означает, что любое колесо, которое зависело от libpythonX.Y.so.1, может не выполнить импорт.

Итак, мне интересно, SWIG генерирует оболочки python для функций C и, очевидно, использует libpython функции, поэтому компоновщик попытается связать libpython , что manylinux не обеспечивает. Если я правильно понимаю, я должен каким-то образом оставить ссылки висящими / несвязанными, и интерпретатор предоставит эти символы во время выполнения при загрузке разделяемой библиотеки, но как я должен скомпилировать это в первую очередь?