This continues the description of the problems I'm having getting a
PyI-built application to run on a machine other than the one it was
compiled on. (The original message is at the bottom for reference.)
At Martin's suggestion, I tried building with the development version --
no luck. (I should mention, though, that after downloading the
development version, it complained about the "support" folder missing.
I copied support/ from the 2.0 version and it started working.
Actually, I also had to replace BUILDPATH by WORKPATH in the .spec file,
so I could copy the manifest file from the build folder; it isn't copied
to the dist folder automatically.)
Following a suggestion on the web, I added specific entries for the
msvc*.dll files to the EXE entry in the spec file, like this:
exe = EXE( pyz,
a.scripts,
a.binaries + [('msvcp90.dll',
path.join(msvcpath,'msvcp90.dll'), 'BINARY'),
('msvcr90.dll',
path.join(msvcpath,'msvcr90.dll'), 'BINARY') ],
name=distpath,
debug=False,
strip=False,
upx=True,
console=False )
(where msvcpath is defined as
r'C:\Windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.1_none_99b61f5e8371c1d4'
to pick up the later version of the files.)
This had no effect; I still get the "side-by-side configuration is
incorrect" message. Looking at the build output, and the "out*" files
in the build folder, I see that the 9.0.21022.8 version is referenced.
Off the top of my head, I'd guess this might be because PyI is looking
to the Python folder's files to get the version ID.
I also ran the bindepend utility, and it showed:
CCAuthLogBrowser.exe
set([u'x86_Microsoft.VC90.MFC_1fc8b3b9a1e18e3b_9.0.21022.8_none',
'KERNEL32.DLL',
u'x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.0.0_none', u'x86_Microsoft.VC90.CRT_1fc8b3b9a1e18e3b_9.0.21022.8_none',
'WS2_32.dll', 'USER32.dll'])
At this point, I'm stumped. Even if I could get the 9.0.30729.6161
references built in, or some other version, it might not be present on
all the machines it'll need to run on.
What I'd really like is something like "static linking", so all the
dependent files are in the .exe, and will be in the MEI_ folder at run
time. (I'm hoping that will be sufficient, and that the executable
won't ignore the "local" files and go searching winsxs.)
Any ideas?
On 9/4/13 11:41 AM, Don Dwiggins wrote:
I'm building a utility (32 bit) with PyI that needs to be runnable on
machines with different Windows versions. (For reference, I'm using
PyI 2.0 at the moment, and Python 2.7.2.)
The generated manifest filereferences VC90.CRT and VC90.MFC at version
9.0.21022.8. When I run it on my machine (Win 7 Pro), Process
Explorer shows it's picked up 9.0.30729.6161 of the MSVC[pr].dll
files. When I copy the .exe and manifest to another machine (Server
2008R2), it fails, with the "attempt to load the C runtime library
incorrectly" message. The event trace shows:
Component identity found in manifest does not match the identity of
the component requested. Reference is
Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
Definition is
Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.1".
(The sxs folders show a third version of the files: 9.0.30729.4926.)
Changing the version numbers in the foo.exe.manifest file has no effect.
Stepping back from the gory details for a moment: what I really want
is to not have to worry about what might be in the Windows/winsxs of
the target machines.I found a discussion of this at
https://groups.google.com/forum/#!topic/pyinstaller/4a9Nb2zgteo, where
the recommendation was to add an 'a.binaries' entry to force inclusion
of a particular version of the DLLs.I'll give that a try, startingwith
9.0.21022.8.
However, I'd like to know if anyone has a better suggestion. At this
point, the whole SxS thing smells to me like the latest edition of DLL
Hell. (For an example of Visual C++ users struggling with this, see
http://stackoverflow.com/questions/59635/app-does-not-run-with-vs-2008-sp1-dlls-previous-version-works-with-rtm-versions)
Thanks for any good words,
--
Don Dwiggins
Advanced Publishing Technology
--
You received this message because you are subscribed to the Google
Groups "PyInstaller" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
[email protected].
To post to this group, send email to
[email protected].
Visit this group at http://groups.google.com/group/pyinstaller.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"PyInstaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pyinstaller.
For more options, visit https://groups.google.com/groups/opt_out.
