Am 20.09.2010 15:21, schrieb Giovanni Bajo:
On 9/19/2010 7:22 PM, Florian Höch wrote:
Ok, I've made progress. I added a lot of print's and tracked the error
to the uuid module from the standard library.
Actually, using r854 does not solve the underlying problem. The problem
is that uuid uses ctypes.find_library and ctypes.CDLL to find and load
the C standard library to access some of its functions. With Python 2.6
and later, this is msvcr90.dll.
If you build an executable with pyinstaller r854, the msvcr90.dll will
be in a subfolder Microsoft.VC90.CRT and is simply not found by
ctypes.find_library. Normally this would throw an exception, but it is
catched and then silently ignored inside uuid.
If you build with pyinstaller r855 and later, msvcr90.dll will be next
to the executable. There, it will be found by ctypes.find_library, and
when it tries to load it using ctypes.CDLL, the R6034 error dialog
appears (before it throws the exception, which is silently ignored like
I said). The application should run normal after that if it not
absolutely requires access to the C library via ctypes (uuid should work
regardless as far as I can tell).
All applications that actually require access to the C library via
ctypes will probably fail at some point, regardless of the pyinstaller
version used to create them.
Thanks for the analysys. A possible solution would be to patch
find_library at runtime through a runtime hook (and its cousing
find_msvcrt(), which is a shortcut to find_library("c") under Windows,
as far as I can tell).
But what should we do? My understand is that CDLL() simply calls
LoadLibrary() on Windows. Why LoadLibrary("msvcr90.dll") fails when the
application is packaged by PyInstaller? If I understand correctly it
fails whether if the DLL is in a subdirectory (silent fail) or the DLL
is next to the executable (R6034). Is it really impossible for a
PyInstaller-packaged binary to dynamically load msvcr90.dll? What would
be the correct Win32 API code to do it? Maybe there is some activation
context needed?
Yes, the activation context is the (afaik only) problem.
A solution would be to add the VC90 assembly dependency to the
executable's manifest, but this breaks onefile builds if users don't
have the VC90 runtimes installed. A workaround for that could be having
two executables for onefile builds: One without manifest, which just
extracts the embedded archive to the temporary directory, and the other
one with manifest, part of the archive, which is then launched by the
'stub' unpacker executable.
I understand that CRT is probably the most important package, but such a
solution would not fix the same issue for different assemblies, as far
as I can tell. So if someone is using ctypes to access a DLL which is
part of an assembly, it would stop working when packaged by PyInstaller.
Right. We could add the other dependent assemblies to the exe's manifest
too though, which would fix that issue.
--
Florian Höch
--
You received this message because you are subscribed to the Google Groups
"PyInstaller" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pyinstaller?hl=en.
