Могу ли я управлять архитектурой (32-битная или 64-битная) при создании исполняемого файла pyinstaller?

Краткий вопрос
Есть ли способ контролировать / гарантировать архитектуру (32-битную против 64-битной) при создании исполняемого файла pyinstaller?

Общие сведения
Я перешел с py2exe на pyinstaller из-за отсутствия поддержки 64-битной версии, а также из-за множества мелких вещей, которые мне трудно игнорировать. Поэтому я предпочел бы , а не вернуться к нему. Я разработал два приложения с использованием 64-битного Python 2.7, и у меня возникают проблемы с производительностью при работе на 32-битных машинах.

Первый - это простой графический интерфейс wxPython (версия 2.9), который подключается к файлу Windows DLL для драйвера USB. Этот вариант кажется довольно "безопасным" для работы в 32-битном режиме, потому что нет только 64-битных модулей. Однако это приложение при работе на 32-битной Windows XP имеет ужасные проблемы с производительностью при разговоре с USB-устройством.

Второе приложение намного больше, и я еще не пытался создавать и запускать из-за опасений архитектурных проблем. В этом приложении используются только 64-битные модули (psycopg2 для одного). Я бы не хотел делать это, если невозможно запустить как 32-битный исполняемый файл.

Текущие мысли
Я считаю, что это возможно (если модули имеют 32-битную поддержку), запустив build.py с Python в 32-битном режиме. Есть ли в этом смысл?

Обновление
У меня было несколько прорывов в первой создаваемой мной программе. Оказывается, проблемы с производительностью были связаны исключительно со скоростью двух машин. Моя машина разработчика имела достаточно мощности, чтобы достаточно быстро опросить USB-устройство, а гораздо более медленная тестовая платформа (Windows XP) - нет.

Я исправил эту проблему, изменив способ опроса USB-порта. Теперь, когда это было исправлено, я мог запускать exe в обеих системах. При попытке собрать исполняемый файл как единый файл возникла новая проблема. При запуске Build.py pyinstaller он извлекает все необходимые библиотеки DLL, которые необходимо запустить приложению. Поначалу казалось, что это отлично работает, но когда я попытался запустить единственный исполняемый файл, который я создал на 64-битной Windows 7, он не работал в Windows XP, потому что DLL USB-ключа не была распознана как допустимая DLL.

Чтобы запустить единственный исполняемый файл в обеих системах, я сначала попытался удалить DLL из файла .spec (который выглядит как сценарий Python). Это было удобно, потому что я мог изменить список включений до команды сборки с помощью обычных модификаторов списка Python. Я надеялся, что если DLL не будет найдена во временном каталоге exe, она найдет ее в системном PATH. Хотя этот подход мог бы работать, я не мог заставить его работать без большого количества ошибок.

Моей второй попыткой было собрать приложение на машине Windows XP (оставив встроенную DLL) в надежде, что DLL Win XP будет работать в Windows 7. Успех! Эта конфигурация работает хорошо; однако я твердо верю, что это не лучшее решение, поскольку оно зависит исключительно от более старой библиотеки DLL, работающей в более новой ОС.