On Mon, May 16, 2011 at 5:08 AM, Zachary Pincus <zachary.pincus@yale.edu> wrote:
Hi Dan,
I see there has been some recent activity on Windows issues in the last few days, but I didn't see anything exactly related to this issue, so I opened ticket: https://github.com/stefanv/scikits.image/issues/22 (I only mention this because I don't know if anyone besides Stefan gets notified when an issue is created). The traceback and other details are in the issue on github.
I tried manually loading FreeImage.dll using ctypes in an ipython session and had the same issue, checking FreeImage's header file shows that the function should be there though. Anyone have any ideas on what else I can try?
I suspect it's not just FreeImage_GetPitch that isn't visible, but all FreeImage_ API calls. (You could check this easily enough though...) I think GetPitch is just the first one that gets looked up.
My guess is that the library on Win7 has different name mangling than is expected. I think that in general the library gets loaded as a "cdll" instead of a "windll" on windows, which appears to work with my limited testing on a XP 32-bit virtual machine. Perhaps try loading the library as a windll via ctypes and then see if any of the symbols are visible.
Or you could dump the dll's symbol table and see what's there... (MinGW has some tools for this -- pexports I think? I bet there are MS tools for the same as part of VC++ but I have no idea.)
Sorry to not be more direct help, Zach
Hi Zach, Loading the library with WinDLL worked (unfortunately in the freeimage plugin code it looks like that's handled by numpy.ctypeslib.load_library which apparently doesn't support anything other than cdll). I read up on ctypes and saw that you can also call functions by ordinal. So loading FreeImage.dll using the cdll calling convention and accessing via ordinal worked fine as well. So I'm not sure what your preferred fix would be, I guess just changing the load code to handle cdll versus windll is more clear than mapping functions to ordinals. -Dan