Python 2.6 on Windows seems to mostly work
Raoul Snyman
I'm using PyInstaller from SVN and Python 2.6 on Windows (XP and 7),
and it's working well. However, I'm using --onedir, rather than --
onefile (I have plugins written in Python that I need to load). I am
getting one or two problems though, and I looked at both the tickets
mentioned in other threads (#38 and #39), and they only seem to deal
with the --onefile.
One of the biggest problems is that even though I can see the chardet
egg in my output directory, one of my plugins doesn't seem to be able
to load it (I get the "no module named chardet" error). I also noticed
that if I build it on Windows 7, Vista and XP can't run it. I haven't
tried it on XP -> Vista/7 yet though.
Lastly, it pops up an error message when my application starts up that
I'm accessing the C runtime incorrectly. I click OK, and my
application runs fine, but obviously I would rather I didn't have this
problem.
Does anyone have any suggestions for me? Should I rather go back to
Python 2.5?
Florian Höch
the #39 patch resolves assembly dependencies under Windows, ie. users do
not have to install the MSVCRT90 runtimes (the error "accessing the C
runtime incorrectly" occurs if those are not resolved), --onefile or
--onedir doesn't matter. It probably doesn't help with the egg problem.
You need pywin32 for the patch to do it's magic.
One known issue with the patch is with Matplotlib (which is solvable
though without hacking into pyinstaller code, it just means 'true'
onefile deploys are not possible when using Matplotlib because the
MSVCRT90 runtimes will need to be installed even when using the patch),
otherwise it seems to work fine.
If you continue having issues even after applying the patch to the
latest pyinstaller trunk, it'd probably be best to go back to Python 2.5
if you can.
Regards,
Florian Höch
Raoul Snyman
> the #39 patch resolves assembly dependencies under Windows, ie. users do not
> have to install the MSVCRT90 runtimes (the error "accessing the C runtime
> incorrectly" occurs if those are not resolved), --onefile or --onedir
> doesn't matter.
I applied your patch, but it didn't do anything. It adds that manifest
directory, but the "cannot load runtime" message still appears.
> It probably doesn't help with the egg problem. You need pywin32 for the
> patch to do it's magic.
I have pywin32 installed. Other libraries like SQLAlchemy and lxml
seem to be compiled to pyd's, but chardet isn't. Perhaps that is the
reason.
> If you continue having issues even after applying the patch to the latest
> pyinstaller trunk, it'd probably be best to go back to Python 2.5 if you
> can.
Meh. Looks like I'll have to do that.
--
Raoul Snyman
B.Tech Information Technology (Software Engineering)
E-Mail: raoul....@gmail.com
Web: http://www.saturnlaboratories.co.za/
Blog: http://blog.saturnlaboratories.co.za/
Mobile: 082 550 3754
Registered Linux User #333298 (http://counter.li.org)
Florian Höch
> I applied your patch, but it didn't do anything. It adds that manifest
> directory,
Yes, that's about all which is supposed to happen. Does the directory
Microsoft.VC90.CRT contain all of the following files:
Microsoft.VC90.CRT.manifest
msvcm90.dll
msvcp90.dll
msvcr90.dll
and are those files also no-where else in the output directory?
> but the "cannot load runtime" message still appears.
The exact wording of the message would be interesting. "accessing the C
runtime incorrectly" and "application configuration is incorrect" would
hint at a problem with an assembly dependecy, others probably not.
Even though going back to Python 2.5 is probably the best option for you
atm, I'd still like to troubleshoot.
Can you give me a list of the modules you're using and also a list of
files in the output directory when building with Python 2.6?
Thanks.
Regards,
Florian Höch
Raoul Snyman
> Yes, that's about all which is supposed to happen. Does the directory
> Microsoft.VC90.CRT contain all of the following files:
> Microsoft.VC90.CRT.manifest
> msvcm90.dll
> msvcp90.dll
> msvcr90.dll
Yes.
> and are those files also no-where else in the output directory?
No. There's a msvcr90.dll file in the output directory - IIRC when
building if those msvc* files weren't in Python's DLL directory.
> The exact wording of the message would be interesting. "accessing the C
> runtime incorrectly" and "application configuration is incorrect" would hint
> at a problem with an assembly dependecy, others probably not.
Yes, the error is "accessing the C runtime incorrectly". Sorry I
haven't been clear about that!
> Even though going back to Python 2.5 is probably the best option for you
> atm, I'd still like to troubleshoot.
>
> Can you give me a list of the modules you're using and also a list of files
> in the output directory when building with Python 2.6?
Since it's for an open source project, I've built an installer for our
testers to play around with. You're welcome to download and look at
the files in the installer. You can get the installer from
http://openlp.org/files/installers/OpenLP-1.9.1-setup-pre2.exe.
Because of the plugins, I've had to write some "hook-*" files to pull
in the plugins at build time. As far as I can see, PyInstaller is
pulling in all the required modules/packages.
If you need anything else from me, please let me know.
Raoul Snyman
On 1 March 2010 12:23, Raoul Snyman <raoul....@gmail.com> wrote:
> No. There's a msvcr90.dll file in the output directory - IIRC when
> building if those msvc* files weren't in Python's DLL directory.
... then PyInstaller would complain about the files not being there.
Florian Höch
>
> On 1 March 2010 12:23, Raoul Snyman<raoul....@gmail.com> wrote:
>> No. There's a msvcr90.dll file in the output directory - IIRC when
>> building if those msvc* files weren't in Python's DLL directory.
>
> ... then PyInstaller would complain about the files not being there.
Do I follow you correctly, you have moved the msvcrt90.dll into
C:\Python26\DLLs yourself, otherwise Pyinstaller would complain about
the missing file? But this was before applying the #39 patch, right?
The thing is, the msvc90* files cannot be used without the accompanying
manifest, which is what the patch takes care of (among a few other
things). Could you try removing that file from Python26's DLL directory?
Pyinstaller shouldn't complain with the patch. There definitely
shouldn't be any loose msvc90 files in the output dir after running
Build.py.
Regards,
Florian Höch
Raoul Snyman
> Do I follow you correctly, you have moved the msvcrt90.dll into
> C:\Python26\DLLs yourself, otherwise Pyinstaller would complain about the
> missing file? But this was before applying the #39 patch, right?
> The thing is, the msvc90* files cannot be used without the accompanying
> manifest, which is what the patch takes care of (among a few other things).
> Could you try removing that file from Python26's DLL directory? Pyinstaller
> shouldn't complain with the patch. There definitely shouldn't be any loose
> msvc90 files in the output dir after running Build.py.
Yay! It works! Thanks Florian!
Now just to figure out why chardet doesn't want to load...
Giovanni Bajo
Do you think this is a situation that could be detected and diagnosed by
PyInstaller?
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com
Raoul Snyman
> Do you think this is a situation that could be detected and diagnosed by
> PyInstaller?
I manually added those files to the Python DLL directory, so I'm not
sure that it's really necessary if Florian's patch is in place.
BTW, Florian, I had to rerun the Configure.py to get PyInstaller to
stop moaning about the missing DLL in Python's DLL directory.
Giovanni Bajo
> On 1 March 2010 20:33, Giovanni Bajo <ra...@develer.com> wrote:
> > Do you think this is a situation that could be detected and diagnosed by
> > PyInstaller?
>
> I manually added those files to the Python DLL directory, so I'm not
> sure that it's really necessary if Florian's patch is in place.
Yes, but you weren't able to solve your problems by yourself, and there
was no diagnostic to help you. In many years of PyInstaller, I've seen
so many "broken" environments you wouldn't believe :)
The policy I would like to follow is: "if it works by running python
foobar.py, it must run after packaging as well, no matter what the
environment is". Either that, or we should at least error out (or
provide a warning, in case we can't be sure).
This is why I'm asking Florian if there is a way to detect this
situation.
Florian Höch
yes, I agree. This situation should be detectable. I think what happened
in this case was as follows: msvcr90.dll in Python26\DLLs directory
(added manually), #39 patch not applied. Configure.py -> Makespec.py ->
Build.py, now the msvcr90.dll is in the output directory.
Patch gets applied -> the DLL is skipped, but it's already in the output
dir. So, maybe it would be enough if we cleared the output dir when
running Build.py?
Does this sound about right?
- Florian
Giovanni Bajo
> Hi Giovanni,
>
> yes, I agree. This situation should be detectable. I think what happened
> in this case was as follows: msvcr90.dll in Python26\DLLs directory
> (added manually), #39 patch not applied. Configure.py -> Makespec.py ->
> Build.py, now the msvcr90.dll is in the output directory.
> Patch gets applied -> the DLL is skipped, but it's already in the output
> dir. So, maybe it would be enough if we cleared the output dir when
> running Build.py?
> Does this sound about right?
Yes, I believe there have been many bugs in the past because of the
output dir not being cleaned up. If you could come up with a patch, I'd
be happy to review and apply it.
Raoul Snyman
> Patch gets applied -> the DLL is skipped, but it's already in the output
> dir. So, maybe it would be enough if we cleared the output dir when running
> Build.py?
In my case, I hadn't run Configure.py again after applying the patch.
So because of this, even though I had cleared my build and dist
directories, I was still getting the DLL being copied across.
Florian Höch
an updated ticket #39 patch is, I removed config['EXE_dependencies'] in
Build.py (and also in Configure.py), and always determine those
on-the-fly in Analysis() when running Build.py.
This has also the benefit that python's assembly depencies are the first
ones to be included, thus I do not necessarily need to add assembly
DLLs to the exclude list anymore (because pyinstaller will not look for
DLLs that are already included), which makes it a bit more future-proof.
I'll make a separate patch for the dist directory clearing first, the
updated #39 patch will follow a bit later (preferably after the dist
clearing patch got reviewed and included).
Regards,
Florian
Florian Höch
existing, non-empty output directory. It will also alert the user of the
fact and allow him to confirm or deny the operation.
http://www.pyinstaller.org/ticket/160
- Florian