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
