On 03.05.2015 14:25, Fabrice Popineau wrote:
Hi,
I don't know if it is right to pollute this list with my problems in trying to compile graph-tool for Win64. I'll try to make it brief. Using MSYS2/MinGW64, I managed to compile the whole src/graph modules and install them as *.pyd modules in the site-packages/graph_tool directory, along with the Python files. Unfortunately, I get a segfault when importing graph_tool.libgraph_tool_core . The segfault happens deep in libboost_python3.
Before posting a long backtrace, maybe someone may offer some clue on what is happening. I have posted some details about what I did below.
The backtrace would actually be helpful.
The background is: python 3.4, boost 1.57, clang 3.5.1 (g++ 4.9.2 as provided with mingw64 couldn't compile a few objects without segfaulting). Is it possible that there is a conflict among those libs/tools (of thread model for example)?
Did you guarantee that Boost.Python was compiled with exactly the same Python version that you used to compile graph-tool? It could also help if you compile everything with the same compiler.
Currently I have configured like this: ./configure --enable-debug --disable-optimize CFLAGS="-I/mingw64/include" LDFLAGS="-L/mingw64/lib" CC=clang CXX='clang -std=c++11 -m64 -DMS_WIN64=1' CXXCPP='clang -E -std=c++11 -m64 -DMS_WIN64=1' PYTHON=python3 Then I run 'make -k -j 8' to compile all the objects. Linking the various dlls fails, because under Windows, you can't link graph_tool_centrality.dll without referencing grap_tool_core.dll.a. However the build process is not prepared to do that and in the right order. So I manually replicated what libtool does, ie :
clang -std=c++11 -shared -nostdlib C:/Local/MSys64/mingw64/x86_64-w64- mingw32/lib/dllcrt2.o C:/Local/MSys64/mingw64/x86_64-w64-mingw32/lib/crtbegin.o .libs/*.o C:/Local/MSys64/mingw64/x86_64-w64-mingw32/lib/crtend.o - L/mingw64/lib -O3 - Wl,--export-all-symbols -Wl,--as-needed -o .libs/libgraph_tool_core.dll -Wl,-- enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgraph_tool_core.dll.a -lpython3.4m -lboost_iostreams -lboost_python3 - lboost_regex -lboost_system -lCGAL -lgmp -lcairomm-1.0 -lcairo -lexpat -lbz2 - lstdc++ -lpthread -lgcc_s -lgcc -lmoldname -lmingwex -lmingw32 -lmsvcrt - ladvapi32 -lshell32 -luser32 -lkernel32
for s in ${subdirs}; do (cd $s ; clang -std=c++11 -shared -nostdlib C:/Local/MSys64/mingw64/x86_64-w64- mingw32/lib/dllcrt2.o C:/Local/MSys64/mingw64/x86_64-w64-mingw32/lib/crtbegin.o .libs/*.o C:/Local/MSys64/mingw64/x86_64-w64-mingw32/lib/crtend.o ../.libs/libgraph_tool_core.dll.a -L/mingw64/lib -O3 -Wl,--export-all- symbols -Wl,--as-needed -o .libs/libgraph_tool_$s.dll -Wl,--enable-auto-image- base -Xlinker --out-implib -Xlinker .libs/libgraph_tool_$s.dll.a -lpython3.4m - lboost_iostreams -lboost_python3 -lboost_regex -lboost_system -lCGAL -lgmp - lcairomm-1.0 -lcairo -lexpat -lbz2 -lstdc++ -lpthread -lgcc_s -lgcc -lmoldname -lmingwex -lmingw32 -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32) done
for i in `find . -name \*.dll` ; do cp $i /mingw64/lib/python3.4/site- packages/graph_tool/`basename $i .dll`.pyd; done
At this point, the modules are installed.
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
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. -- Tiago de Paula Peixoto <tiago@skewed.de>