Obviously this works for most people, so it has to be something specific
to your system. Nonetheless, it's still a bug that we need some help to
sort out.
Does it work in one-dir mode? And in one-file mode? What Python version
are you using? What operating system are you running on?
Can you please send:
* The full output of Build.py
* A list of all files bundled in one-dir mode
Thanks!
--
Giovanni Bajo :: ra...@develer.com
Develer S.r.l. :: http://www.develer.com
My Blog: http://giovanni.bajo.it
Last post: Compile-time Function Execution in D
Am 10.01.2011 12:30, schrieb Stefan Fruehwirth:
> Hi,
>
> when running a standalone executable using arbitrary code like this
> line:
>
> ---
> print "confusing cat..."
> ---
>
> I get a dialog box "Microsoft Visual C++ Runtime Library" with the
> following text content:
>
> ---
> Runtime Error!
> Program: [path-to-program]
> R6034
> An application has made an attempt to load the C runtime library
> incorrectly.
> Please contact the application's support team for more information.
> ---
This problem has been reported before, unfortunately, the cause is still
somewhat in the dark.
>
> The code execution resumes, output is correct. However, I tried to
> narrow it down and found out that the error disappears when I put a
> "progName.exe.manifest" file with following content in the same
> directory:
Interesting. Normally, this file should be generated automatically by
pyinstaller (in --onedir mode, it should land in the output folder along
with the exe, in --onefile mode, it should be part of the archive
embedded in the final executable, which can be checked with
pyinstaller's ArchiveViewer.py).
Regards
--
Florian Höch
I noticed that the bootloader executables contain a manifest as resource
since some time (I don't know since when, but some of my older exe's do
not contain it). While this doesn't lead to problems on my setup, it may
be related to the R6034 error reported by others. Can we get rid of the
manifest in the bootloader? The only contents seem to be security
options for Vista/Win7, which I could add to the manifest generated by
pyinstaller (I already added it to my local build, it was a trivial
change, but I didn't commit yet).
Regards
--
Florian Höch
Hi Florian,
there is a 0-byte manifest.xml in source/windows; I messed up with it,
it should have been removed after your patch (after the manifest is
generated by Build.py).
As for the embedded manifest in the executables, I don't know how it
gets there... can you please have a look?
> While this doesn't lead to problems on my setup, it may
> be related to the R6034 error reported by others. Can we get rid of the
> manifest in the bootloader? The only contents seem to be security
> options for Vista/Win7, which I could add to the manifest generated by
> pyinstaller (I already added it to my local build, it was a trivial
> change, but I didn't commit yet).
Yes, we can get rid of it, I don't think it should be generated in the
first place, and I don't know if it's useful or not. So, rather than
regenerating it from your patch, can you please check how it gets added
to the executable?
Maybe through the new build system? Martin?
The maanifest seems really getting there through the new build system.
When using visual studio compiler, the manifest is always generated.
Giovanni, could you please verify if MSVC 2003 uses lingflag /MANIFEST
during compilation?
You could get compilation details with using waf option -vv:
python waf -vv build
Part of waf code where manifest is handled:
http://code.google.com/p/waf/source/browse/tags/waf-1.5.18/wafadmin/Tools/msvc.py?r=10833
Maybe other useful information:
http://code.google.com/p/waf/issues/detail?id=595
Should I try to change the new build system to not embed manifest to
bootloader?
I will check, but I was trying to use VS2008 to build the bootloader,
given the availability of the free-as-in-beer express version.
> Part of waf code where manifest is handled:
> http://code.google.com/p/waf/source/browse/tags/waf-1.5.18/wafadmin/Tools/msvc.py?r=10833
>
> Maybe other useful information:
> http://code.google.com/p/waf/issues/detail?id=595
>
> Should I try to change the new build system to not embed manifest to
> bootloader?
Yes please. It would be great if you could hack something "dirty and
quick" so that we can at least check if it's related to the R6034 issue
that people are experimenting. After this check, we can decide what's
the best way forward to implement a clean solution.
Thanks!
The --onefile Build.py log looks fine I think, also the --onedir contents.
Can you run
pyinstaller\ArchiveViewer.py <path-to-your-onefile-executable>
and post the list of files?
Regards
--
Florian Höch
Another test: change your program so that it prints
os.environ["_MEIPASS2"] and doesn't exit immediately; then, while it is
running, go to the temporary directory that was printed and check if the
manifest file is there.
Hmm, maybe, but I somehow doubt it :) My bets are currently on getting
rid of the redundant manifest resource in the bootloader, hoping that
this will already be enough to eventually fix the problem (it could be a
race condition between WinSxS automatically grabbing the manifest
resource, thus somehow blocking pyinstaller's own attempt at loading the
correct manifest. But that's really just my speculation at the moment).
Regards
--
Florian Höch
I've just committed an updated bootloader in SVN trunk (thanks to Martin
for disabling manifest generation), for Windows 32-bit.
Stefan, can you please try again with SVN trunk? (assuming you are not
using 64-bit Python on 64-bit Windows)
--
Giovanni Bajo :: Develer S.r.l.
ra...@develer.com :: http://www.develer.com
What I did was that when compiling bootloader the manifest file is not
embedded to executable by manifest tool 'mt.exe'.
However there is still passed link flag '/MANIFEST' to the compiler. So
if it still won't work we could try something with this flag (disable,
etc.).
This is explanation of this flag:
http://msdn.microsoft.com/en-us/library/f2c0w594(v=vs.80).aspx
Martin
I don't think it matters: that flag just asks the linker to create the
manifest on the disk. Since we don't copy it over from the build
directory, nor embed it anymore with mt.exe, it does not affect the
generated executable, as far as I can tell.
--
Giovanni Bajo :: ra...@develer.com
Develer S.r.l. :: http://www.develer.com
My Blog: http://giovanni.bajo.it
Just to be sure, is the manifest missing in the temp location a new
problem? Is the manifest still present in the executable archive?
(I thought from your last answer to Giovanni that the manifest was
actually extracted succesfully then)
Regards
--
Florian Höch
Just to make sure: did you unpack PyInstaller in a different directory
(no reuse of internal bincache directories) and did you rebuild the
application from scratch (no reuse of build temporaries)?
--
Giovanni Bajo :: ra...@develer.com
Develer S.r.l. :: http://www.develer.com
My Blog: http://giovanni.bajo.it
Can you please build in debug mode (debug=1 in the spec) and console
(console=1 in the spec), then run the program from the command line and
tell me the output on the console before the message box appears, and
after.
Is anybody able to reproduce it? I will try that.
I'm trying to reproduce this issue on my winxp sp3 En with python 2.6.5.
I'm not able to reproduce that yet. PyInstaller works in both modes
(onedir and onefile).
I think there must be something unusual in your system. Can you think of
anything?
What is the output of your %PATH% variable? command:
echo %PATH%
And what is the real value of 'path-to-user-dir' from your debug output?
Or just if it does not contain any localization characters.
Regards Martin
When the bootloader is compiled with the link flag '/MANIFEST', the name
of the executables are:
run.exe
runw.exe
run_d.exe
runw_d.exe
So the manifest file should be in this case:
run.exe.manifest
runw.exe.manifest
run_d.exe.manifest
runw_d.exe.manifest
However. when a python app is frozen and the exe file renamed is it
supposed that the file name of the manifest will be
new_app_name.exe.manifest?
Stefan or anybody else having this error could try rename the manifest
file to anything from the following, if it will work:
run.exe.manifest
runw.exe.manifest
run_d.exe.manifest
runw_d.exe.manifest
This is just an idea what else to try. Is really anybody able to
successfully reproduce this error?
The bootloader does the equivalent of sys.argv[0]+".manifest". Since it
dynamically loads the manifest, it works unless the end user renames the
executable (which is never supported by PyInstaller, eg. it breaks the
multi-package mode).
What makes me worried is the following text from
http://msdn.microsoft.com/en-us/library/f2c0w594(v=vs.80).aspx
----
If you specify /MANIFEST, the name of the manifest file will be the same
as the name of your output file, with .manifest appended to the file
name. For example, if your output file name is MyFile.exe, the manifest
file name will be MyFile.exe.manifest. If you
specify /MANIFESTFILE:name, the name of the manifest will be what you
specify in name.
----
So I think that when using the linkflag '/MANIFEST' the name of the
required manifest file is hard coded in the executable to values like
'run.exe.manifest' and that loading manifest file dynamically is then
overriden.
Let's try to compile bootloaders also without the linkflag /MANIFEST if
and we'll see if it could help.
I think you're mixmatching the issues.
/MANIFEST only generates the manifest on the disk. If you remove that
flag from the linker command line, the manifest is simply not
generated. /MANIFEST does not modify the executable in any form.
For a manifest to be automatically loaded and activated by the operating
system, there are two ways:
* Either the manifest is on the disk, next to the executable, with the
same name of the executable plus ".manifest"
* or the manifest is embedded within the executable (embedding is
usually achieved through the mt.exe tool after linking).
In the case of PyInstaller, we load and activate the manifest "manually"
through Win32 APIs in one-file mode (since it's extracted to the temp
directory); in one-dire mode, the OS loads it automatically since it
sits there on the disk next to the executable.
So is the problem that in onefile mode the manifest is missing and this
causes the Runtime Error R6034 and so we need to find out why the
manifest is missing and fix it?
Could you pleases summarize the symptoms in onefile/onedir mode and what
you tried, what helped and what not?
Could you please publish somewhere the exe of your test example so I
could try that if it's failing for me?
Thanks in advance.
Martin
So do you use as username this string 'früwirt'?
Something very strange (imho) is happening when I try and launch this
executable on my Win7 64 system (only sys I tried to run it on so far):
I get an UAC dialog ("Do you want to allow the following program from an
unknown publisher to make changes to this computer?"). Very unusual, has
never happened to me (with pyinstaller).
If I click OK in that dialog, I get the console window with the first
part of the debug output, then the R6034 error. After I click OK in the
error dialog, the second half of the output is displayed; after I close
the executable by hitting the return key, I get a Windows dialog "This
program might not have installed correctly" with the usual choices
"Reinstall using recommended settings" or "This program was installed
correctly".
Honestly, I have not the slightest idea what is going on there :)
Can anyone reproduce the behavior I described? (I should note that I
have UAC on the highest setting, but even returning it to the default
showed the same results)
Regards
--
Florian Höch
Can you please compare the differences between this binary and the same
binary packaged by PyInstaller on your own computer? Since the program
itself is a one-liner, and you can install the very same version of
Python, it should be possible to compare the binary file by file and see
where the difference lies.
I downgraded to Python 2.6.5 and built an executable.
Comparing the contents of the two exe's using ArchiveViewer.py:
pyInstallerR6034Issue.exe (mine)
pos, length, uncompressed, iscompressed, type, name
[(0, 567033, 567033, 0, 'z', 'outPYZ1.pyz'),
(567033, 8308, 22705, 1, 'm', 'iu'),
(575341, 169, 234, 1, 'm', 'struct'),
(575510, 5988, 15712, 1, 'm', 'archive'),
(581498, 1157, 2272, 1, 's', '_mountzlib'),
(582655, 81, 76, 1, 's', 'useUnicode'),
(582736, 84, 81, 1, 's', 'pyInstallerR6034Issue'),
(582820, 38275, 96256, 1, 'b', 'win32api.pyd'),
(621095, 6011, 11776, 1, 'b', 'select.pyd'),
(627106, 233097, 585728, 1, 'b', 'unicodedata.pyd'),
(860203, 36925, 71680, 1, 'b', 'bz2.pyd'),
(897128, 602, 1857, 1, 'b', 'Microsoft.VC90.CRT.manifest'),
(897730, 317595, 655872, 1, 'b', 'msvcr90.dll'),
(1215325, 155722, 568832, 1, 'b', 'msvcp90.dll'),
(1371047, 66835, 224768, 1, 'b', 'msvcm90.dll'),
(1437882, 1054327, 2145280, 1, 'b', 'python26.dll'),
(2492209, 42972, 110592, 1, 'b', 'pywintypes26.dll'),
(2535181, 274, 488, 1, 'b', 'pyInstallerR6034Issue.exe.manifest')]
http://ling.uni-graz.at/~fruehwir/pyInstallerR6034Issue.exe
pos, length, uncompressed, iscompressed, type, name
[(0, 681871, 681871, 0, 'z', 'outPYZ1.pyz'),
(681871, 8361, 24593, 1, 'm', 'iu'),
(690232, 169, 234, 1, 'm', 'struct'),
(690401, 6022, 16832, 1, 'm', 'archive'),
(696423, 1157, 2272, 1, 's', '_mountzlib'),
(697580, 81, 76, 1, 's', 'useUnicode'),
(697661, 108, 111, 1, 's', 'pyInstallerR6034Issue'),
(697769, 39920, 87552, 1, 'b', '_ctypes.pyd'),
(737689, 5444, 10240, 1, 'b', 'select.pyd'),
(743133, 231896, 583680, 1, 'b', 'unicodedata.pyd'),
(975029, 35130, 69632, 1, 'b', 'bz2.pyd'),
(1010159, 391031, 805376, 1, 'b', '_ssl.pyd'),
(1401190, 38022, 95744, 1, 'b', 'win32api.pyd'),
(1439212, 20385, 43008, 1, 'b', '_socket.pyd'),
(1459597, 602, 1857, 1, 'b', 'Microsoft.VC90.CRT.manifest'),
(1460199, 317595, 655872, 1, 'b', 'msvcr90.dll'),
(1777794, 155722, 568832, 1, 'b', 'msvcp90.dll'),
(1933516, 66835, 224768, 1, 'b', 'msvcm90.dll'),
(2000351, 1049758, 2262528, 1, 'b', 'python26.dll'),
(3050109, 42514, 109568, 1, 'b', 'pywintypes26.dll'),
(3092623, 274, 488, 1, 'b', 'pyInstallerR6034Issue.exe.manifest')]
So looking at the file sizes there are numerous differences, also some
extras, _ctypes.pyd, _socket.pyd and _ssl.pyd. I'm using python.org
Python, maybe the other is ActiveState?
Am 20.01.2011 19:38, schrieb Giovanni Bajo:
> On Thu, 2011-01-20 at 15:47 +0100, Florian Höch wrote:
>>> http://ling.uni-graz.at/~fruehwir/pyInstallerR6034Issue.exe
>>
>> Something very strange (imho) is happening when I try and launch this
>> executable on my Win7 64 system (only sys I tried to run it on so far):
>
> Can you please compare the differences between this binary and the same
> binary packaged by PyInstaller on your own computer? Since the program
> itself is a one-liner, and you can install the very same version of
> Python, it should be possible to compare the binary file by file and see
> where the difference lies.
--
Florian Höch
Hi Stefan, do you use python installer from www.python.org or from
http://www.activestate.com/?
Great to hear that we know the cause of this issue.
We should clearly state on pyinstaller website that it is know to not
work with ActivePython, at least on windows platform.
I'm glad that the issue is resolved ;)