Работает PyUNO в Django

Question

У меня есть клиент, работающий с SUSE Enterprise Server 11, на котором я хочу использовать django-проект с OpenOffice-Python-Bridge, который называется PyUNO, Он запускает apache2 с mod_wsgi и не имеет virtualenv или что-то.

Я добавил соответствующий путь к PYTHONPATH, но когда я запускаю оболочку python manage.py shell и попробовать import unoЯ получаю эту ошибку:

dynamic module not initialized properly

Это OpenOffice 3.4, python 2.6.x (оба с SUSE-DVD).

Google привел меня к системной переменной LD_LIBRARY_PATH, но как только я установил его, я больше не могу запустить оболочку, потому что python больше не может найти django (PYTHONPATH, похоже, как-то не работает). Если я бегу ldconfig -v /path/to/openoffice/program/ что является еще одним распространенным предложением, результат тот же.

После выполнения одного из перечисленных выше действий я могу запустить общесистемный python и импортировать uno. Но я больше не могу запускать django-shell, потому что django не найден.

Если я сбросил LD_LIBRARY_PATH (через unset LD_LIBRARY_PATH или же ldconfigЯ попадаю в "старую" ситуацию.

OpenOffice поставляется в комплекте с бинарным Python. Этот может импортировать uno без ошибки.

Результат: я думал об использовании другого uno.py или как-то сказать apache2 использовать python-версию, поставляемую с openoffice. Как я могу сделать что-то подобное или добавить соответствующие pyuno-зависимости в python-версию, используемую apache? Или какая версия openoffice/pyuno могла бы решить мою проблему? Я бы хотел не трогать mod_wsgi и python из SUSE-источников.

Также могут быть полезны некоторые подсказки о LD_LIBRARY_PATH.

Answer 1

LD_LIBRARY_PATH - это переменная, которая переопределяет путь поиска для разделяемых библиотек (обычно так.)

Когда вы устанавливаете его, например, экспортируете LD_LIBRARY_PATH=/opt/test/mylibs, вы заставляете все приложения искать общие библиотеки в этом месте.

Это объясняет, почему django-shell не может быть запущен, потому что он ищет библиотеки там, где их нет.

Хорошей новостью является то, что LD_LIBRARY_PATH может быть установлен на несколько путей, разделенных двоеточиями (:). Таким образом, вы можете экспортировать LD_LIBRARY_PATH=/opt/test/mylibs:/opt/another/path

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

Я не знаю, однако, является ли это истинной проблемой, с которой вы сталкиваетесь, но я думаю, что это может дать вам некоторое представление о значении этой переменной.