Giovanni Bajo wrote:
> Which operating system are you using? If it's Windows XP, which service pack?

This has occurred on at least two Win XP machines, one at SP1 and the 
other at SP2.

> Uhm. This is in fact pretty weird. The point is that if MSVCR71.DLL wasn't 
> found by Windows in the DLL search path, the program would not even start: 
> PYTHON24.DLL requires it, and so all the .PYDs do.

I've finally figured out what's going on -- you'll be relieved to know 
it's not PyInstaller's fault.  For reference, in case someone else 
stumbles onto this, here's the essence of it:

In addition to pyodbc, I'm using osql.exe (a SQL Server utility) to run 
SQL batch files on the database, starting it up using os.popen3 so I can 
catch the error output.  The problem is, apparently, that the PyI-built 
app's environment isn't inherited by the subprocess (and yes, osql needs 
msvcr71.dll); compounding the problem was that osql dies silently when 
it can't find the dll.

I tried switching to subprocess.Popen, which has an env= argument, but 
that didn't work either, due to a subtle problem in the way it calls 
Windows CreateProcess.  (See 
http://mail.python.org/pipermail/python-dev/2004-October/049656.html for 
the gory details.)

So, unless someone has any bright ideas, I'm going to have to work 
around this one way or another.  I'll probably go back to the 
py2exe-style approach of just ensuring that msvcr71.dll is in the 
directory with the executable whenever I use an exe, that needs that 
dll, in a subprocess.

Thanks for the assistance anyway,

-- 
Don Dwiggins
Advanced Publishing Technology


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"PyInstaller" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/PyInstaller?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to