Tiago de Paula Peixoto <tiago <at> skewed.de> writes:
I can't vouch for this way of compiling things, since I'm very unfamiliar with the windows build environment. But doing things by hand like this seems very invasive. A better approach would be to investigate why autotools is not building things right, and fix that. A quick google search reveals things like: http://gnuwin32.sourceforge.net/packages/autoconf.htm
Actually, I know quite well this gnuwin32. I'm building with MSYS2/MinGW64 for x86_64. DLLs do not work quite the same under Windows and under Linux. Libtool is of not much help here. The way you build your set of modules can't work like this under Windows. You need to link every other dll with libgraph_tool_core.dll.a There is no automatic import of symbols. (Actually, it is possible to write an init function for the dll, but nothing like this is provided automatically) The segfault I got was because g++ (actually cc1plus.exe) ran out of resources. It used about 4Gb and crashed. However, I managed to overcome the problem and I have the whole set of dlls (renamed *.pyd) modules that I can import in Python. Given the g++ crash, I tried to compile them with clang, but the layout of bjects must be different. The dlls compiled fine, but I couldn't import them into python. Anyway ...
The only thing to change on the Python side is to remove the calls to getdlopenflags() and setdlopenflags() which are not available to Windows.
This may be fatal. In GNU/Linux, for instance, this is necessary to guarantee lazy evaluation of symbols when importing. I have no idea if this is necessary in windows, and if so, what are the alternative approaches to dlopen.
... I may have a problem here. I don't know yet. I have exported all symbols by default in all *.pyd modules. Currently, I can't yet import all from graph_tool because of a bug in pycairo. Slowly progressing. Fabrice