On Tue, Apr 30, 2013 at 4:05 PM, Tamás Nepusz
<address@hidden> wrote:
> In the call, __name__ is "igraph._igraph" and __file__ is "/usr/local/lib/python3.2/site-packages/python_igraph-0.6.5-py3.2-cygwin-1.7.18-i686.egg/igraph/igraph_core.cpython-32m.dll". The file is there. I've tried calling imp.load_dynamic manually from within the directory containing the DLL (e.g. "imp.load_dynamic('igraph._igraph','igraph_core.cpython-32m.dll')"). I tried adding the directory to LD_LIBRARY_PATH. Same result in all cases.
Okay, I think the problem here is that imp.load_dynamic is looking for a specific symbol within the loaded DLL file and the name of this symbol is derived from the filename. This is what the Python docs say about the issue [1]:
"The initialization function must be named PyInit_name, where name is the name of the module, and should be the only non-static item defined in the module file:"
[1]: http://docs.python.org/3.0/extending/extending.html#the-module-s-method-table-and-initialization-function
It does not matter what name you pass to imp.load_dynamic in the first argument, it will always use the second argument. So, the problem is that by renaming _igraph.cpython-32m.dll to igraph_core.cpython-32m.dll, Python will look for a symbol named PyInit_igraph_core in the DLL instead of PyInit__igraph. I think that you have to edit igraphmodule.c in the source code of the Python interface, replace the single occurrence of PyInit__igraph to PyInit_igraph_core (and also replace every occurrence of "igraph._igraph" with "igraph.igraph_core" while you are at it), replace "igraph._igraph" in setup.py with "igraph.igraph_core" as well, and recompile the Python interface. Hopefully this will create a "proper" igraph_core module within igraph that will not confuse Cygwin.
Please keep me posted; if it works, I will definitely fix it in the next release.
python-igraph-0.6.5.cygwin.patch