Это двоякий вопрос ... Контекст вопроса - получение хорошей сборки Python 3.1.1 для использования при сборке и запуске mod_wsgi. Видеть этот документ для получения дополнительной информации о том, почему общая библиотека - хорошая идея.
Каковы последствия создания Python с --enable-shared?
Я заметил, что когда я создаю его БЕЗ --enable-shared, двоичный файл python составляет ~ 16 МБ.
-rwxr-xr-x 2 root root 1638104 Aug 17 12:29 python3.1
С --enable-shared размер двоичного файла python составляет 15 КБ.
-rwxr-xr-x 2 root root 15860 Oct 5 22:34 python3.1
В общем, что это делает с «нормальными» операциями Python? Все ли скрипты по-прежнему будут работать? Какое-либо влияние на производительность? Можете ли вы, или желательно, иметь и то, и другое (общее и статическое)?
Есть идеи, как решить эту ошибку чисто?
Примечание: построено на чистой 64-битной установке RHEL 5.3.
После сборки Python 3.1.1 с ./configure --enable-shared, Я получаю эту ошибку:
[root@test ~]# python3
python3: error while loading shared libraries:
libpython3.1.so.1.0: cannot open shared object file: No such file or directory
Я решил это, разместив эту символическую ссылку:
/usr/lib64/libpython3.1.so.1.0 -> /usr/local/lib/libpython3.1.so.1.0
Что кажется довольно хакерским ... Есть ли параметры ./configure, которые можно передать, чтобы вылечить это?
-
Спасибо!
Вероятно, это для superuser.com, но ладно, я укушу.
Каковы последствия создания Python с --enable-shared?
Вы получаете двоичный файл, который использует динамический загрузчик для связи с необходимыми библиотеками, ничего плохого в этом нет. Когда какая-либо из библиотек, от которых зависит ваш двоичный файл, обновляется, следующий вызов этого двоичного файла дает больше преимуществ, чем следующая сборка.
В общем, что это делает с «нормальными» операциями Python?
Ничего.
Все ли скрипты по-прежнему будут работать?
Да.
Какое-либо влияние на производительность?
Если вас беспокоит быстрое создание процессов Python, статическое связывание выполняется немного быстрее.
Можете ли вы, или желательно, иметь и то, и другое (общее и статическое)?
Конечно, можете, но с динамическими двоичными файлами все в порядке, нет необходимости в каких-либо статических двоичных файлах, если вы не знаете, что они вам нужны.
Есть идеи, как решить эту ошибку чисто?
Отредактируйте /etc/ld.so.conf, добавьте «/ usr / local / lib» в отдельную строку, запустите ldconfig
Есть ли параметры ./configure, которые можно передать, чтобы вылечить это?
Просто догадываюсь ... --prefix = / usr
Я сам столкнулся с этой проблемой в 64-битной системе Fedora и нашел не столько ответ, сколько, по крайней мере, объяснение для себя:
Эта ошибка Python существует с 2003 года и до сих пор применяется к версии 3.1: есть --libdir флаг для configure который должен иметь возможность установить каталог библиотеки, но на самом деле он ничего не делает; библиотеки Python всегда устанавливаются в "PREFIX/lib". Ошибка заставила нескольких разработчиков объяснить, почему это так (на данный момент). Итак, в моем случае для Fedora выполняется:
./configure --enable-shared --prefix=/usr
Мне пришлось бежать
ln -s /usr/lib/libpython3.1.so.1.0 /usr/lib64/libpython3.1.so.1.0
после установки, чтобы заставить его работать. Так что да, это немного взломано, но пока так работает сборка Python.
Для тех, кто возвращается к этому, это правильное решение:
Отредактируйте /etc/ld.so.conf или создайте что-нибудь в /etc/ld.so.conf.d/, чтобы добавить / usr / local / lib и / usr / local / lib64. Затем запустите ldconfig.