On 29 Jan., 17:45, kfj <[email protected]> wrote:
> Okay, I can't think of anything else. You'll have to debug it. Once > you have the stack trace, we can have a look at where the actual crash > occurs and take it from there. Having slept over the matter, I can think of some more things. First we must be sure that all components used are compatible. After all there's four things involved: - hugin - SWIG - Python - MSVC In the Linux world, things tend to integrate more easily because everything is built with gcc and updates come when they're ready, for free. Using Windows, there are some pitfalls to be avoided, and there are also differences to accepted standards. The first bit concerns Python. This is what actually made me think along these lines: I noticed from a bit of output you'd copied from a python interpreter session that you were using Python 2.7. That is quite recent, and though it should be compatible with the previous 2.X versions, there might be subtle differences. When CMake finds the Python Libs, I think it says which version it has found and is linking against. We should be sure these are of the same Python Version. Then I thought some more and it occured to me that the problems surface when using ebmbedded Python, namely when using hpi from hugin. Embedding hugin effectively links a Python interpreter into hugin, and again we must be sure it's the same version that we use otherwise. More so, we have to be sure that it has been compiled using the same Version of MSVC as the one we've used to compile the SWIG module with (and, ideally, the same we're compiling hugin with). In section 4.1 of the Python document 'Extending and Embedding the Python Interpreter' it is stated that: "To build extensions using these instructions, you need to have a copy of the Python sources of the same version as your installed Python. You will need Microsoft Visual C++ “Developer Studio”; project files are supplied for VC++ version 7.1, but you can use older versions of VC ++. Notice that you should use the same version of VC++that was used to build Python itself." So, to make a long story short, everything should be compiled with the same version of MSVC and all Python parts should be of the same python version. The Python interpreter, when fired up, should tell you what version it's been built with. The second bit I found was from the SWIG documentation. It states: "3.4 Microsoft extensions and other Windows quirks A common problem when using SWIG on Windows are the Microsoft function calling conventions which are not in the C++ standard. SWIG parses ISO C/C++ so cannot deal with proprietary conventions such as __declspec(dllimport), __stdcall etc. There is a Windows interface file, windows.i, to deal with these calling conventions though. The file also contains typemaps for handling commonly used Windows specific types such as __int64, BOOL , DWORD etc. Include it like you would any other interface file, for example: %include <windows.i> __declspec(dllexport) ULONG __stdcall foo(DWORD, __int32);" This might be worth a try. Okay, that's all I can think of for now - I'm not familiar with MSVC, that's why I can't be more specific, but maybe the difficulties that have surfaced with the embedded Python in hpi stem from here. Kay -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
