Executable problem - socket?
Gib Bogle
My student has been developing a GUI (using PyQt and PyQwt) that runs a model
written in Fortran and built as a DLL. She has to present on this work
tomorrow. She makes an executable version of the Python code with py2exe, and
the executable runs fine on her Vista laptop and my XP machine. It doesn't run
on the PC that she must use for her talk tomorrow. The Fortran DLL code is
started up, it writes some text output to a couple of log files, then it fails
with a WindowsError (000001d) which is a write error. I suspect that this is
the first attempt to write to a socket (communication from the DLL to Python is
via sockets). The only clue is that the machines that her program runs on have
Python installed, while the one that fails doesn't. Therefore I suspect that
py2exe has omitted a necessary Python DLL. How can I track down what might be
missing?
Thanks
Gib
MRAB
Gib Bogle
Wow! I've heard of it, but never used it. The result is intriguing, but
baffling. When I look at the executable ABM15.exe on my machine (where it runs
OK), I see a couple of harmless messages, but interestingly the program shows up
with a checksum inconsistency, between Link Checksum and Real Checksum.
Apparently this causes no issues on my machine.
On another XP machine, where the program fails with the write error, there is
first a pop-up with this message:
"Errors were detected when processing ABM15.exe. See the log for details."
In the log there are two significant messages:
"Error: The side-by-side configuration information for ABM15.exe contains
errors. The application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this problem
(14001)."
(the checksum discrepancy is there also)
"MSJAVA.DLL Error opening file. The system cannot find the file specified (2)."
(needless to say, I'm not using Java, and MSJAVA.dll is not on the other machine
either)
I find it very puzzling that the "configuration information" (whatever that is)
is OK on one machine and erroneous on another. DependencyWalker is obviously
onto something - but what?
(At this stage snide comments about Windows will be received without comment.)
Gib Bogle
actually fails to execute at all, complaining about the configuration
information. Therefore I'm seeing different behaviour on three XP machines:
Box 1 (SP2): runs OK
Box 2 (SP3): fails to start
Box 3 (SP3): starts up, all Qt stuff works, fails after invoking the Fortran DLL
Just to add to the confusion, execution is successful on a Windows 7 box.
I forgot to mention that the laptop on which the program was built (and where it
runs OK) is using Vista. I now see that it will probably be necessary to build
separate Vista and XP versions - I should have realized this earlier, but was
misled by the fact that the Vista-built program runs OK on my XP SP2 box.
Sean DiZazzo
Did you compile the program with python 2.6? Try compiling with 2.5.
~Sean
Gib Bogle
I'll have to check with Helvin, but I believe 2.6 was needed for the version of
PyQt that she has installed.
Gib Bogle
> You could try Dependency Walker: http://dependencywalker.com/
>
I have (belatedly) read the py2exe tutorial:
http://www.py2exe.org/index.cgi/Tutorial#Step522
and learned about the msvcr90.dll issue. I haven't finished sorting this out
yet, but I did find that running vcredist_x86.exe (the right version!) on box 1
fixed things there. I also tried (naively) manually adding
dist\Microsoft.VC90.CRT with the manifest file and msvcr90.dll, but this doesn't
seem to work - it seems that p2exe must do the file copying.
Lawrence D'Oliveiro
> The only clue is that the machines that her program runs on have
> Python installed, while the one that fails doesn't.
Wouldn’t it be a whole lot simpler to install Python on the bloody machine?