py2exe not agreeing w/ libpandaexpress

i’ve had good luck bundling panda games with py2exe under panda v1.3.2.

this is my first time trying to get the same to work with 1.4.2 and i’m having some difficulty. i run the game with no problems from the command line, but when i compile to .exe i have two different problems:

on the development system i get a crash complaining about FFMpegTexture’s capabilites. my game plays a movie with synchronized audio, so i’m using a MovieTexture for the playback. but the .exe version loads the texture into an FFMpegTexture and i get the following error:

Traceback (most recent call last):
  File "", line 246, in ?
  File "", line 26, in __init__
  File "", line 139, in setupIntro
AttributeError: 'libpanda.FFMpegTexture' object has no attribute 'synchronizeTo'

what would cause the .exe to create an FFMpegTexture instead of a MovieTexture?

the second snag is on a clean proposed target system, where the problem is more immediate, but slightly harder to understand.

Traceback (most recent call last):
  File "", line 1, in ?
  File "pandac\PandaModules.pyo", line 1, in ?
  File "pandac\libpandaexpressModules.pyo", line 1, in ?
  File "pandac\extension_native_helpers.pyo", line 20, in ?
ImportError: DLL load failed: The application failed to start because the application configuration is incorrect.  Reinstalling the application may fix this problem.

the line where the failure occurs is

from libpandaexpress import *

libpandaexpress.dll is included in the package, but i don’t know about what sort of python bits are necessary to support it.

  1. Try putting:
use-movietexture 1

in the Config.prc file you distribute with your application.

  1. Is it possible you are getting a conflict with a different version of ilbpandaexpress.dll in some other folder?


  1. the game uses loadPrcFile() to load a custom prc whether it’s run from the command line or packaged. i have confidence that it’s being loaded because the window dimension and decorated-ness is different from etc/Config.prc. also, both my custom file and etc/Config.prc have
use-movietexture #t

2)no, the destination machine does not have panda installed, nor are there any other versions of libpandaexpress.dll on the file system, on the PATH or otherwise.

  1. Looking at the code, it appears that use-movietexture is queried only exactly once, at application startup–it can’t be changed at runtime (it’s already too late). So you will need to have an actual prc file that is loaded automatically, not explicitly loading a prc file at runtime.

  2. Perhaps one of the other dll’s that libpandaexpress depends on was omitted from your distribution. Try the command:

dumpbin /dependents libpandaexpress.dll

to list all of the DLL’s that libpandaexpress requires.


  1. so rather than keeping my configuration in game_dir/config/GameConfig.prc, i will place it in game_dir/etc/Config.prc and not call loadPrcFile().

  2. well, there’s definitely a mismatch there. i will investigate and report back.

same thing happened here :

  1. Worked like a charm

  2. I thought that error message looked familiar. It’s because I’ve seen this:

Application failed to start because EXAMPLE.dll was not found. Reinstalling the application may fix this problem.

before when libraries were missing for various reasons. This is a general Windows error message, which can be caught and wrapped in an ImportError by python.

The difference (“application configuration”, here) is that it was the .manifest file from the Microsoft redistributable c runtime that was missing. That’s Microsoft.VC80.CRT.manifest for those keeping score at home. I’ll reserve my opinions about the manifest situation.

So that mostly solved things. The last snag, which was easy to fix once I was entrenched in the problem, was that pandaopenal32.dll wasn’t in my list of data files. Easily resolved.

Could someone enlighten me about the name of this file? I’d expect it to be either a) OpenAL32.dll or b) libp[3|anda]openal32.dll if it was the openal redistributable or a panda interface to openal, respectively. Has panda modified the openal source or something?

Thanks for all your help.

We’ve had lots of problems over the years with people having conflicts with different versions of a dll required by Panda already installed on their system. For instance, a different version of zlib.dll, or cg.dll, or any number of other “standard” dll’s, would cause havoc and cause Panda to mysteriously fail, often in messy ways.

We finally solved the problem by custom-renaming most or all of the third-party dll’s that Panda uses. Now it doesn’t matter what version of zlib.dll you might have already installed, since Panda will load pandazlib.dll instead.

I suspect that openal32.dll went through a similar renaming.