2013-04-03 2 views
2

Я могу использовать cx_freeze для упаковки моего инструмента python, но мне не нужна загруженная библиотека. По какой-то причине выводимое исполняемое/двоичное имя продолжает включаться в путь.cx_freeze встраивает мою библиотеку разделяемых объектов в двоичный исполняемый файл?

я получаю следующее сообщение об ошибке:

OSError: /home/derekx/sbu/build/exe.linux-x86_64-2.7/secure_boot_utility/lib/libcrypto.so.1.0.0: не могу открыть файл разделяет объект : Не каталог

библиотека получает упаковано /home/derekx/sbu/build/exe.linux-x86_64-2.7/lib/libcrypto.so.1.0.0

созданное двоичный «secure_boot_utility» является также в файле build/exe.linux86_64-2.7.

Входящие скрипты и setup.py находятся в/home/derekx/sbu.

Я использовал «питон setup.py сборки», чтобы упаковать инструмент/зависимостями ..

Любая помощь будет принята с благодарностью. Я попробовал комбинацию параметров, но все равно получаю ту же ошибку.

Мой setup.py является:

import sys 
from cx_Freeze import setup, Executable 

sys.path.append('sbu_scripts/') 
sys.path.append('lib/') 

binincludes = ['libcrypto.so.1.0.0'] 
binpaths = ['/home/derekx/sbu/lib'] 
includefiles = [('lib/libcrypto.so.1.0.0','lib/libcrypto.so.1.0.0'),] 

exe = Executable(
    script="secure_boot_utility.py", 
    ) 

setup(
    name = "SecureBoot", 
    version = "0.1", 
    description = "Test Secure Boot", 
    options = {"build_exe": {'copy_dependent_files':True, 'create_shared_zip':True, 'bin_includes':binincludes, 'bin_path_includes':binpaths, 'include_files':includefiles}}, 
    executables = [exe] 
    ) 
+0

Я этого раньше не видел. Можете ли вы попробовать скопировать библиотеку в ту же папку, что и исполняемый, а не в подпапку 'lib /'? –

+0

Да. Опция «copy_dependent_files»: True, похоже, копирует несколько библиотек, которые мне нужны (включая libcrypto) на том же уровне, где создается исполняемый файл. Если я включил include_files, чтобы скопировать один уровень вверх, я все равно получаю ту же проблему, когда запускаю исполняемый файл. Спасибо –

+0

Если я добавлю zip_include, чтобы библиотека была добавлена ​​в zip-файл как lib/libcrypto.so.1.0.0, я все равно получаю ту же ошибку :( –

ответ

2

Я не уверен, почему каталог верхнего уровня (getcwd) является имя исполняемого.

В любом случае, я смог добавить что-то в свой код с помощью os.path.exists и перенастроить значение, отправленное в LoadLibrary.

Спасибо, Томас, за то, что нашли время ответить.

Это изначально чужой инструмент, который мне пришлось поддерживать. Что случилось, sys.path [0] использовался, чтобы получить текущую рабочую директорию для создания полного пути к загружаемым библиотекам. Я не уверен, почему исполняемый файл, созданный с помощью cx_freeze, всегда вставлял исполняемое имя в текущий рабочий каталог.

Как я установил это, был проверен, если полный путь к библиотеке, которая получает сконструированную существовал с os.path.exists:

if os.path.exists(path_to_lib) is False: 
    path_to_lib = LibName 

return path_to_lib 

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

+0

Добро пожаловать. Кстати, это хорошая практика, чтобы показать решение, которое вы разработали для более поздних читателей. Есть несколько вещей, которые расстраивают, когда вы обнаруживаете, что кто-то уже решил проблему, связанную с вашим, и не сказал, как это сделать. –

+1

Добавил, что я сделал. Еще раз спасибо –

+0

Кстати, причина, по которой исполняемый файл находится в sys.path, состоит в том, что с некоторым вариантом исполняемый файл может иметь прикрепленный к нему файл zip, содержащий модули pure-python. –

Смежные вопросы