Hi John, In my case, all I needed was a PyFile_AsFile to get the File *. However I found that Python errors going to stdout/stderr were not being redirected properly when my code was linking to a different version of the CRT than the build of Python I was using.
In the end, I came up with one of two solutions, and I really don't like recommending either: 1) Rebuild Python with a different compiler/linker kit so it links to the same CRT as my project, in your case find a mingw built Python.dll 2) Rebuild my project so it links to the same CRT as the Python.dll, have you got 3 hours to spare, then read on... Python2.5 out of the msi links against msvcrt71.dll, and I found the free VS2003 toolkit compiler which produces binaries that link against this CRT (microsoft no longer provide this because its been superceded by the VS2005 express editions) archived here: http://xona.com/2004/06/29.html Also you will need to download .Net 1.1 (~120mb) to get msvcrt71.lib More complete details about setting up the free VS2003 command line compiler are here... http://root.cern.ch/root/Procedure/Procedure%20to%20install%20the%20free%20Microsoft%20Visual%20C.htm On 3/21/07, John Pye <[EMAIL PROTECTED]> wrote: > Hi Carl > > I'm not sure that your snippet really solves my problem. As far as I can > see from, you're just passing a filename instead of a file pointer, > right? And then you're using the Python fopen-equivalent > (PyFile_FromString) This is not an option for me, as I want to pass the > FILE* from Python and all the way into into a existing shared-library > code. I can't change the latter; it must work ok with standard fprintf > (etc) functions. > > If I've missed something, perhaps you could clarify a little bit more on > how it is that you're overcoming the FILE* problem? > > Cheers > JP > > See also > http://groups.google.com/group/comp.lang.python/browse_frm/thread/7b69b34240169f7e/ac8fae1b61832f51?lnk=st&q=file+mingw+python&rnum=30#ac8fae1b61832f51 > > And > http://mail.python.org/pipermail/python-list/2007-March/430695.html > http://groups.google.com/group/comp.lang.python/browse_frm/thread/6d7569e7fd996daf/ > http://groups.google.com/group/comp.lang.python/browse_frm/thread/17558adbc053f26d/ > > Carl Douglas wrote: > > Hi John, > > > > I had exactly this problem... use the PyFile_AsFile function. Below > > is a code snippet from my project: > > > > // Thank you: http://www.ragestorm.net/tutorial?id=21#8 > > PyObject* PyFileObject = PyFile_FromString(ofn.lpstrFile, "r"); > > > > if (PyFileObject == NULL) > > { > > PyErr_Print(); > > PyErr_Clear(); > > return false; > > } > > > > // Because microsoft C runtimes are not binary compatible, we > > can't > > // just call fopen to get a FILE * and pass that FILE * to > > another application > > // or library (Python25.dll in this case) that uses a > > different version > > // of the C runtime that this DLL uses. Using PyFile_AsFile is a > > work-around... > > > > if (PyRun_SimpleFile(PyFile_AsFile(PyFileObject), > > ofn.lpstrFile) == -1) > > { > > PyErr_Print(); > > PyErr_Clear(); > > } > > > > Py_DECREF(PyFileObject); > > > > For the full source of my SWIG/Python project, poke around here: > > > > http://l3dtpython.googlecode.com/svn/trunk/cdPython/ > > > > Hope that helps. > > > > On 3/21/07, John Pye <[EMAIL PROTECTED]> wrote: > >> Hi all > >> > >> There is fairly well-known problem on MinGW with passing FILE pointers > >> to Python. The problem seems to be that Python depends on a different > >> version of msvcrt*.dll to that which MinGW depends on, and these > >> different C runtimes provide different FILE implementations. > >> > >> The upshot of that seems to be that file objects created in Python via > >> the 'file(...)' command can't safely be used in a SWIG module. It can be > >> done perfectly (using SWIG typemap and PyFile_AsFile) on Linux but it > >> fails with a segfault on Windows. > >> > >> What is the best possible workaround for this? Surely someone must have > >> found a satisfactory solution to this problem? > >> > >> Cheeers > >> JP > > -- > John Pye > Department of Mechanical and Manufacturing Engineering > University of New South Wales, Sydney, Australia > http://pye.dyndns.org/ > > -- http://mail.python.org/mailman/listinfo/python-list