2013-07-31 5 views
1

Я пытаюсь заморозить код Python 3.3, который использует библиотеки PySide, используя cx_freeze, и все это в Windows XP (x86, SP2/3) ,PySide (1.1.2), cx_freeze, WinXP, Python 3.3: ImportError: Ошибка загрузки DLL

В python setup.py build работает успешно, но исполняемый Выдает ImportError:

ImportError: DLL load failed: This application has failed to start because the application configuration is incorrect. Reinstalling [...]

То же сборках работать прекрасно на Windows 7 x64 (SP1).

версии я использую следующие:

  • Python 3.3.0 (v3.3.0: bd8afb90ebf2, 29 сентября 2012, 10:55:48) [MSC v.1600 32 бит (Intel) ] на win32
  • cx_Freeze-4.3.1.win32-py3.3
  • PySide-1.1.2.win32-py3.3

Обе библиотеки Qt DLL копируются в папку сборки (QtCore.dll, QtGui.dll), библиотека-zip содержит оба .pyc equivale nts в папке/модуле PySide.

Эта проблема возникает даже с простейшей тест-кода ( , а также если код выполняется на установке «живой» Python и *):

from PySide import QtCore, QtGui 

if __name__ == "__main__": 
    app = QtGui.QApplication("My Application") 
    win = QtGui.QMainWindow() 
    win.show() 
    app.exec_() 

Использование более вверх-to дата версии PySide может решить проблему, но с PySide 1.2.0 вводит новую проблему с cx-freeze (ошибка загрузки файла) Мне было интересно, удалось ли кому-либо успешно заморозить пакет PySide на складе Windows XP?

В противном случае придется подождать, пока PySide 1.2.1 не будет опубликован и сохранит мои надежды на этот выпуск.

  • Оставить комментарий: Я не уверен, действительно ли это произошло во время моих испытаний по той же причине или по другим причинам, например. фактический модуль вызывает проблему в замороженных сборках что не установлен должным образом ..
+0

Вы говорите, что проблема возникает, когда код запускается на живой установке Python? Значит, это не относится к замороженным приложениям? –

+0

Да, это то, что я сказал, но это, должно быть, произошло в разгар битвы, когда я тестировал на разных платформах, где фактическая установка модуля (который оказался виновником), возможно, не была установлена ​​должным образом. Я еще не восстановил сценарий, чтобы доказать обратное, но это моя теория. Спасибо, я поставлю его в брекеты, чтобы избежать путаницы. – bossi

ответ

2

Оказался, там было простое решение вопроса: Библиотеки DLL из другого модуль использования приложения отсутствовали; скопировав его в корневую папку для сборки рядом с замороженным EXE, легко решить проблему.

Лучший (и, вероятно, единственный) подход атаки для решения этих проблем, вероятно, состоит в том, чтобы скопировать все библиотеки DLL из используемых модулей в каталог сборки один за другим, пока замороженная сборка больше не выдает ошибку. Я не мог найти другого способа, поскольку stacktrace не указывал на определенный файл, который не загружался.

Если кто-нибудь столкнется с подобными проблемами, я был бы рад предоставить дополнительную информацию.

+1

Люди часто рекомендуют [Проводник процессов] (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx), чтобы узнать, какие DLL-файлы загружают загруженное приложение. –

0

У меня была аналогичная проблема в прошлом, и я смог ее решить, загрузив «Распространяемый пакет Microsoft Visual C++ 2008 (x86)».