On 22/03/2007 15.34, John Pye wrote: > I downloaded your package and installed it in c:/mingw1. It complained > that it could not detect Python, although I have Python 2.4 installed > on my system (did you check HKCU as well as HKLM, perhaps?)
Ewwww you're totally right! I'll have that fixed! > I note that the gccmrt utility does not work from MSYS. You will need > to provide a shell-script equivalent version, in order for that to be > useful for MSYS users. So I opened a cmd prompt and ran the command, > then restarted my MSYS session. Yes, I don't use MSYS. I'll attempt something... any idea how to ship both versions and still having the right one picked up depending on which shell you're using? Maybe it's just a matter of extensions? > There is also a need to be able to > query the *current state* of the gccmrt option. Right, I'll add that. > Next I built my code. It all compiled OK, all the way through to my > NSIS bundle. So that was nice. It includes gfortran, flex, bison, SWIG/ > Python and Tcl/Tk linkage: a bit of a coup. > > BUT when I try to run my program, I get a windows error msgbox, > "python.exe - Entry Point Not Found: The procedure entry point _ctype > could not be located in the dynamic link library msvcr71.dll". In msvcrt71.dll, there is no _ctype (see declaration at line 111 of include\ctype.h). There is only _pctype. What if you comment the declaration at line 111? I wonder what it's bringing in _ctype. Anyway, it looks like mingw-runtime does not support this _ctype change between mscvrt.dll and msvcr71.dll. These changes should probably be represented in the forms of #ifs checking __MSVCRT_VERSION__. I'm not even sure that __MSVCRT_VERSION__ is being set correctly.. that is something gccmrt should eventually take care of, but for this specific _ctype problem you probably need to submit a patch to mingw-runtime. I can guide you through it though... I don't have much time in these days though. -- Giovanni Bajo -- http://mail.python.org/mailman/listinfo/python-list
