How to receive a FILE* from Python under MinGW?

[John Pye]

On Mar 23, 10:59 am, Giovanni Bajo <n... at ask.me> wrote:
> 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!

Great. I'll be looking out for a bugfix release very shortly then ;-)

>
> > 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?

Yes, just add a file 'gccmrt' with no extension, and put '#!/bin/sh'
in the first line, I'd say. And then whatever the script actually
needs to do -- hopefully it's pretty simple. If you need to be
tweaking the registry perhaps it would be better to just write a
little binary .exe that can be used both my cmd and sh users.

>
>  > There is also a need to be able to
>
> > query the *current state* of the gccmrt option.
>
> Right, I'll add that.

Great, that would be a help.

>
> > 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.

Sorry, I'm not clear on this and will need a bit more help. I'm not
even sure where this _ctype dependency could be coming from -- do you
have any ideas?

Are you saying that I can't make your GCC tools work until the MinGW
runtime is patched?

Cheers
JP