Unresolved symbols in MSVCRT.DLL when running a py2exe packaged program.
NoSpam at NoSpam.com
Fri Mar 2 18:07:12 CET 2001
You can distribute system dll's. You are expected to, and sometimes you
have to. You must insure that the version you load is at least equal to the
version that you linked against.
I have done this (distribute system DLL's) on all windows except WinME and
the 16bit ones. Unfortunately I can't say how I did it precisely, because I
just used InstallShield. But I believe that, where SFP exists, you must use
specific and new API's to replace DLL's, otherwise the system will back out
One solution is to specify the changes in an .INF file and let the system
worry about these details (but this has its limitations).
I assume that Python itself updates the MSVCRT.dll. Might look at how it
does it on Win2K.
One way I remember getting the error being described was writing code for
the install process that used the CRT and that got executed before my
version of the CRT got installed.
"Rolander, Dan" <Dan.Rolander at marriott.com> wrote in message
news:mailman.983539023.17143.python-list at python.org...
> I agree with Robin and Gordon's assessment. It's risky at best to
> system dll's with your application, and impossible to upgrade system dll's
> on Win2K because of system file protection.
> -----Original Message-----
> From: Thomas Heller [mailto:thomas.heller at ion-tof.com]
> Sent: Friday, March 02, 2001 8:03 AM
> To: python-list at python.org
> Subject: Re: Unresolved symbols in MSVCRT.DLL when running a py2exe
> packaged program.
> Here is a comment about a similar problem in
> another py2exe-packed application, which
> I received from Jeff Kunce:
> >>I just tried runing a py2exe-packaged application on an older NT
> >>it choked with an "Entry Point Not Found" error on MSVCRT.dll
> >Well, I played with it some more and got it to work.
> >I simply excluded all the DLLs that are normally found in NTs system32
> >directory (MPR.dll, MSVCIRT.dll, MSVCRT.dll, NETAPI32.dll, NETRAP.dll,
> >SAMLIB.dll) - and it works now on the older machine.
> >It looks like there is no easy "good" solution to this problem. Here's a
> >comment by Gordon McMillan on the topic:
> > http://www.wxpython.org/archive/2000-June/002469.html
More information about the Python-list