работает 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, питон 2.6.x (как с SUSE-DVD).

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

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

Если я сброшу LD_LIBRARY_PATH (через unset LD_LIBRARY_PATH или ldconfig), я попал в «старую» ситуацию.

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

Результат: Я думал об использовании другого uno.py или как-то сказать apache2 использовать питон-версию, которая поставляется вместе с 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, и это может будет достаточно, чтобы решить вашу проблему.

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