Runtime error R6034 with python2.6

[Antonio Valentino]

Hi list,
I recently updated my python environment to Python 2.6.2 and PyQt
4.5.4.
I'm experimenting problems packaging an application that worked fine
with the old environment.

At application startup an error dialog is showed:

"Microsoft Visual C++ Runtime Library

Runtime Error!

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."

After closing the dialog *the application seems to work correctly*.

It seems to me that it is a known problem:

http://groups.google.com/group/PyInstaller/browse_thread/thread/4b5d827412deb1c2
http://www.pyinstaller.org/ticket/39

So I woul like to know which is the current status of pyinstaller vs
python2.6.
In order to get it working should I apply all patches attached to
http://www.pyinstaller.org/ticket/39?


thanks

--
Antonio Valentino

[Florian Höch]

Regarding the patch I made for Python 2.6+, it's still "unofficial", and
it requires pywin32 to work ( http://sourceforge.net/projects/pywin32/
). That said, only the most recent patch needs to be applied.

Regards,

Florian Höch

Antonio Valentino schrieb:

[Antonio Valentino]

On 28 Lug, 13:55, Florian Höch <florian.ho...@gmx.de> wrote:
> Regarding the patch I made for Python 2.6+, it's still "unofficial", and

> it requires pywin32 to work (http://sourceforge.net/projects/pywin32/

> ). That said, only the most recent patch needs to be applied.
>
> Regards,
>
> Florian Höch

Thank you very much Florian.

Unfortunately it doesn't seems to work in my case.

I downloaded a fresh svn working copy from trunk and applied patch
pyinstaller-trunk-r681-py26-win-tweaks-20090618.patch.
Then:

$ python Configure.py

Should I update my spec file or make something other?

thanks

> Antonio Valentino schrieb:
>
> > Hi list,
> > I recently updated my python environment to Python 2.6.2 and PyQt
> > 4.5.4.
> > I'm experimenting problems packaging an application that worked fine
> > with the old environment.
>
> > At application startup an error dialog is showed:
>
> > "Microsoft Visual C++ Runtime Library
>
> > Runtime Error!
>
> > 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."
>
> > After closing the dialog *the application seems to work correctly*.
>
> > It seems to me that it is a known problem:
>

> >http://groups.google.com/group/PyInstaller/browse_thread/thread/4b5d8...

> >http://www.pyinstaller.org/ticket/39
>
> > So I woul like to know which is the current status of pyinstaller vs
> > python2.6.
> > In order to get it working should I apply all patches attached to
> >http://www.pyinstaller.org/ticket/39?
>
> > thanks
>
> > --

> > Antonio Valentino- Nascondi testo citato
>
> - Mostra testo citato -

[Florian Höch]

It should work without any changes, but maybe clear/delete the build
directory.
You can check if pyinstaller finds the needed assembly files for Python
2.6 by looking at the output of Build.py (it should print some debug
messages like 'I: Found manifest <path>' and 'I: <filename> part of
assembly <name> dependency of <otherfile>').
Are you doing an one-dir or one-file build? In the former case, the
files Microsoft.VC90.CRT.manifest, msvcm90.dll, msvcp90.dll and
msvcr90.dll should appear in your dist/exe directory when you build, in
the latter case, they will be added to the exe itself - you can check
that with pyinstaller/ArchiveViewer.py <path_to_your_exe>.

Regards,

Florian Höch

Antonio Valentino schrieb:

[Antonio Valentino]

On 28 Lug, 15:20, Florian Höch <florian.ho...@gmx.de> wrote:
> It should work without any changes, but maybe clear/delete the build
> directory.

Yes. Done.

> You can check if pyinstaller finds the needed assembly files for Python
> 2.6 by looking at the output of Build.py (it should print some debug
> messages like 'I: Found manifest <path>' and 'I: <filename> part of
> assembly <name> dependency of <otherfile>').

OK


I: Found manifest C:\WINDOWS\WinSxS\Manifests
\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-
ww_d08d0375.manifest
I: SRCPATH: C:\WINDOWS\WinSxS\Manifests
\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-
ww_d08d0375.manifest
I: Microsoft.VC90.CRT.manifest part of assembly Microsoft.VC90.CRT
dependency of C:\WINDOWS\system32\python26.dll
I: SRCPATH: C:\WINDOWS\WinSxS
\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-
ww_d08d0375\msvcr90.dll
I: msvcr90.dll part of assembly Microsoft.VC90.CRT dependency of C:
\WINDOWS\system32\python26.dll
I: SRCPATH: C:\WINDOWS\WinSxS
\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-
ww_d08d0375\msvcp90.dll
I: msvcp90.dll part of assembly Microsoft.VC90.CRT dependency of C:
\WINDOWS\system32\python26.dll
I: SRCPATH: C:\WINDOWS\WinSxS
\x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_x-
ww_d08d0375\msvcm90.dll
I: msvcm90.dll part of assembly Microsoft.VC90.CRT dependency

> Are you doing an one-dir or one-file build? In the former case, the

one-dir

> files Microsoft.VC90.CRT.manifest, msvcm90.dll, msvcp90.dll and
> msvcr90.dll should appear in your dist/exe directory when you build, in
> the latter case, they will be added to the exe itself - you can check
> that with pyinstaller/ArchiveViewer.py <path_to_your_exe>.

OK

C:\asigrid\gsdview-0.5.x-valentino\win32\dist\gsdview>dir m*
Il volume nell'unità C non ha etichetta.
Numero di serie del volume: 1457-A32A

Directory di C:\asigrid\gsdview-0.5.x-valentino\win32\dist\gsdview

07/11/2007 02.23 1.857 Microsoft.VC90.CRT.manifest
13/04/2008 19.13 59.904 MPR.dll
06/11/2007 21.23 224.768 msvcm90.dll
09/12/2008 15.24 499.712 MSVCP71.dll
07/11/2007 02.19 568.832 msvcp90.dll
09/12/2008 15.24 348.160 MSVCR71.dll
07/11/2007 02.19 655.872 msvcr90.dll
7 File 2.359.105 byte
0 Directory 1.800.060.928 byte disponibili

It seems to be all correct but the error dialog keeps popping up :(.

thanks again

--
Antonio Valentino

[Florian Höch]

Ok, you said it is an PyQt app, so I suspect it may have something to do
with Qt. Can you try building a minimal app with just a print statement
or similar? If that runs, it has to be one of the imported modules that
causes problems. I have not used PyQt before, but I'll try if I can
reproduce the error.

Regards,

Florain Höch

Antonio Valentino schrieb:

[Antonio Valentino]

On 28 Lug, 16:50, Florian Höch <florian.ho...@gmx.de> wrote:
> Ok, you said it is an PyQt app, so I suspect it may have something to do
> with Qt. Can you try building a minimal app with just a print statement
> or similar? If that runs, it has to be one of the imported modules that
> causes problems. I have not used PyQt before, but I'll try if I can
> reproduce the error.

Florian,
testing the patched pyinstaller on an "hello world" program doesn't
give any error.
Also a minimal PyQt4 app seems to work fine so the problem must be
elseware:

numpy,
gdal,
enthought


Do you have any idea of how to solve this kind of problem?
Do you think a "dependency walker" program could help in this case?

Many thanks for you precious help

--
Antonio Valentino

[Florian Höch]

That's good news to some extent. I've just added an updated patch for
pyinstaller (same ticket), bindepend.py <file> can now show dependent
assemblies. Also, when building, assembly files are put into their own
subfolder (good idea to clear both build and dist directories first so
you don't get duplicates from a build with the previous patch). You can
then after building look at all the dependencies of the DLLs with
bindepend.py, maybe this gives a hint at whats going wrong.

Regards,

Florian Höch

[Antonio Valentino]

On 28 Lug, 21:07, Florian Höch <florian.ho...@gmx.de> wrote:
> That's good news to some extent. I've just added an updated patch for
> pyinstaller (same ticket), bindepend.py <file> can now show dependent
> assemblies. Also, when building, assembly files are put into their own
> subfolder (good idea to clear both build and dist directories first so
> you don't get duplicates from a build with the previous patch). You can
> then after building look at all the dependencies of the DLLs with
> bindepend.py, maybe this gives a hint at whats going wrong.

Hi Florian,
I have still not tested your new patch.

Anyway after a further analysis I can confirm that the problem is due
to enthought components, or at least my installation of such
components.

I generated MSI intallers from source using the MinGW compiler and v.
5.1.4 and swig 1.3.39 for win32.

Packages are:

* EnthoughtBase 3.0.3
* Traits 3.2.0
* TraitsGUI 3.2.0
* TraitsBackendQt 3.2.0
* Enable 3.2.0
* Chaco 3.2.0

the test program is:

https://svn.enthought.com/enthought/browser/Chaco/trunk/examples/cursor_tool_demo.py

with the following two lines added before the first enthought import:

from enthought.etsconfig.api import ETSConfig
ETSConfig.toolkit = 'qt4'


Note: pyinstaller seems to have problems with enthought packages so I
copied the site-packages/enthought folder into the dist/
cursor_tool_demo.

Now I'm going to apply your patch for further testing.


Best regards.

--
Antonio Valentino

> >> - Mostra testo citato -- Nascondi testo citato

[Florian Höch]

Hi Antonio,

indeed, my own tests also hinted that enthought packages don't get
included completely by pyinstaller, with or without my patch. I think it
has to do with the way they are packaged.
You said you copied the enthought subfolder into the exe dir? That might
actually be part of the problem, because if any *.pyd files in
subfolders have a dependency on a MS assembly, this assembly has to be
next to the *.pyd files. Can you try duplicating the Microsoft.VC90.CRT
folder (or its contents) and put one into each subfolder with *.pyd
files? No idea if it works, but it might be worth a try.

Regards,

Florian Höch

[Antonio Valentino]

On 29 Lug, 13:43, Florian Höch <florian.ho...@gmx.de> wrote:
> Hi Antonio,
>
> indeed, my own tests also hinted that enthought packages don't get
> included completely by pyinstaller, with or without my patch. I think it
> has to do with the way they are packaged.
> You said you copied the enthought subfolder into the exe dir? That might
> actually be part of the problem, because if any *.pyd files in
> subfolders have a dependency on a MS assembly, this assembly has to be
> next to the *.pyd files. Can you try duplicating the Microsoft.VC90.CRT
> folder (or its contents) and put one into each subfolder with *.pyd
> files? No idea if it works, but it might be worth a try.
>
> Regards,
>
> Florian Höch

OK Florian,
the only places where I can see *.pyd/*.dll fiiles are:

* enthought.chaco
* enthought.chaco.contour
* enthought.traits
* enthought.traits.protocols
* enthought.kiva.agg

I tried

a. manually copy the Microsoft.VC90.CRT direacory
b. copy DDL and manifest file directly in each sub-folder.

Nothing changes.


I just discovered that enthought dev team recently committed a change
to improve py3exe/py2app compatibility:

https://svn.enthought.com/enthought/changeset/24349

I suppose this also helps pyinstaller.

Unfortunately the last stable release don't include that change.
Do you know some manner to embed the fix into a pyinstaller hook?

ciao

--
Antonio Valentino


> Antonio Valentino schrieb:
>

> > On 28 Lug, 21:07, Florian Höch <florian.ho...@gmx.de> wrote:
> >> That's good news to some extent. I've just added an updated patch for
> >> pyinstaller (same ticket), bindepend.py <file> can now show dependent
> >> assemblies. Also, when building, assembly files are put into their own
> >> subfolder (good idea to clear both build and dist directories first so
> >> you don't get duplicates from a build with the previous patch). You can
> >> then after building look at all the dependencies of the DLLs with
> >> bindepend.py, maybe this gives a hint at whats going wrong.
>
> > Hi Florian,
> > I have still not tested your new patch.
>
> > Anyway after a further analysis I can confirm that the problem is due
> > to enthought components, or at least my installation of such
> > components.
>
> > I generated MSI intallers from source using the MinGW compiler and v.
> > 5.1.4 and swig 1.3.39 for win32.
>
> > Packages are:
>
> > * EnthoughtBase 3.0.3
> > * Traits 3.2.0
> > * TraitsGUI 3.2.0
> > * TraitsBackendQt 3.2.0
> > * Enable 3.2.0
> > * Chaco 3.2.0
>
> > the test program is:
>

> >https://svn.enthought.com/enthought/browser/Chaco/trunk/examples/curs...

[Florian Höch]

Sorry, I've played a bit with it, but rather unsuccessfully. I think for
your particular project it might be best to go back to Python 2.5.

Regards,

Florian Höch

Antonio Valentino schrieb:

[Giovanni Bajo]

On mer, 2009-07-29 at 05:11 -0700, Antonio Valentino wrote:

> I just discovered that enthought dev team recently committed a change
> to improve py3exe/py2app compatibility:
>
> https://svn.enthought.com/enthought/changeset/24349
>
> I suppose this also helps pyinstaller.
>
> Unfortunately the last stable release don't include that change.
> Do you know some manner to embed the fix into a pyinstaller hook?

That wouldn't change anything with PyInstaller. In fact, modifying a
package to support py2exe is a pity in itself and part of the reason why
PyInstaller exists.

The commit message is rather terse: "This is necessary due to the use of
namespace packages.". If you could contact the author and ask him to
provide an elaborated description of what the problem is, we can look at
how fix it for PyInstaller.
--
Giovanni Bajo
Develer S.r.l.
http://www.develer.com

[Antonio Valentino]

Il giorno Sat, 01 Aug 2009 17:45:31 +0200
Giovanni Bajo <ra...@develer.com> ha scritto:

FYI:

https://mail.enthought.com/pipermail/enthought-dev/2009-September/024306.html

ciao

--
Antonio Valentino